Troubleshooting API issues with Fiddler
In this post, we’ll learn about troubleshooting API issues with Fiddler. Imagine you’re building an app that incorporates eSignature functionality by using the DocuSign API. You went about things exactly the right way:
- First, you reviewed DocuSign developer resources to learn about integrating with DocuSign and identify which API operations you’ll need to call.
- Next, you tried out those API requests in Postman. So far, so good — everything’s working as intended there.
- Finally, you wrote the code in your app that calls the DocuSign API. To your surprise…it doesn’t work! You’re getting an error message in response to one of your app’s API calls and you have no idea why.
What’s a developer to do in this situation? Well, you know that the API request was successful when sent via Postman, but failed when sent via your app. So, figuring out the problem just requires identifying how your app’s (unsuccessful) API request differs from the (successful) API request sent via Postman. But how? Fiddler to the rescue!
What is Fiddler?
Fiddler is an app that captures HTTP/HTTPS traffic to and from browsers and desktop apps, allowing you to inspect details of API requests and responses as data travels over the wire. It’s perhaps the most popular product in Telerik’s lineup of dev-focused apps, and for good reason. Learn how to use Telerik’s traffic inspector, and API troubleshooting will
be a breeze no longer be such a frustrating task.
Note: This post focuses exclusively on Fiddler’s traffic inspector feature — just one aspect of its overall functionality. To learn more about its other features, check out the product overview info on the Telerik site.
In Intro to REST APIs, we learned that API requests and responses travel ‘over the wire’ between client and server via HTTP(S).
Using Fiddler, you can capture and inspect request and response data in its entirety — including HTTP verbs, HTTP headers, body, cookies, and more. This is particularly useful when one of your API requests results in an error response (or fails to have the intended effect) and you know — from the API documentation and/or from testing requests via Postman — exactly what data a successful request should contain. In this scenario, you can use Fiddler to inspect your request data, piece by piece, comparing it to the successful request in order to identify the issue.
Getting started with Fiddler
Get started with Fiddler by completing the following steps.
Step 1: Determine which Fiddler product is right for you
Fiddler comes in several flavors, so you’ll need to figure out which one is right for you. Personally, I’ve always used Fiddler Classic — a free, Windows-only product. If you’re developing on macOS or Linux (or on Windows but want a more polished UI than Fiddler Classic offers), Fiddler Everywhere is likely the product for you. Checkout the Telerik site for the full lineup of Fiddler products, and pricing info too.
Step 2: Download and install Fiddler
Download and install the Fiddler product that’s right for you. At the time of this writing (June 2022) Fiddler Classic (the older, Windows-only tool) is free, whereas the newer Fiddler Everywhere (available for Windows, macOS, and Linux) is priced at $10 per user per month for individuals and small teams. You can start with a Free Trial (Try for Free), before deciding whether to purchase.
Step 3: Create an API request
For example purposes here, I created an API request in Postman that issues a Get Random Fact request to the Cat Fact API. It’s a simple request that doesn’t require a request body or any parameters.
Step 4: Open Fiddler and issue the API request
Open Fiddler and ensure that live traffic is being captured there. (You should see new entries being written to the Live Traffic pane.) In Postman, choose the Send button to issue the Get Random Fact API request. Doing so will send the API request from Postman on your machine, over the network, to the Cat Fact API server — which will, in turn, return an API response.
Step 5: Examine network traffic in Fiddler
In Fiddler, pause Live Traffic capture (to make it easier to find your Get Random Fact request in the list of captured traffic). In the Live Traffic pane, find the request with the URL corresponding to the Get Random Fact request that you issued from Postman (
https://catfact.ninja/fact). Click on that line item in the Live Traffic pane to see the request and response data for that request.
The following screenshot shows the request and response data for the Get Random Fact request that I issued from Postman. Notice that both the Request pane (top-right pane) and the Response pane (bottom-right pane) contain multiple tabs that you can select from to inspect various parts of the request and response data (e.g., Headers, Params, Cookies, Body, etc.).
So there you have it…
…a brief look at Fiddler — an app that you can use to troubleshoot API issues by inspecting network traffic. If you’re curious to learn more, head on over to the Telerik site and dig right in.
You’ve reached the end of the Tools series! Next, up-level your skills by learning about some Best Practices that’ll save your tons of frustration and wasted time down the road. But first — a quick knowledge check: