Debugging Failed API Calls with Insomnia's Request Inspector

You Got a 401. Now See Exactly What the Client Sent

An API request returns an error and all you know is the status code. You do not know whether the header was missing, the body was malformed, or the server rejected the token. The useful takeaway is that Insomnia's request and response inspector shows the exact HTTP exchange the client performed, so you can debug the request you actually sent rather than the one you intended to send.

What the Inspector Shows

After you send a request, Insomnia displays the outgoing request and the incoming response side by side. You can check the HTTP status code—the three-digit number such as 200 or 401 that indicates success or failure—along with response headers, response body, request headers, request body, and timing. A bearer token is a credential sent in the Authorization header, often prefixed with the word Bearer. The inspector is client-side: it reveals what Insomnia transmitted and what the server returned, not what happened inside the server.

Worked Example: A Missing Bearer Token

Suppose a GET request to https://api.example.com/v1/users returns 401 Unauthorized.

1. Open Insomnia and open the GET request.
2. Set the request URL to https://api.example.com/v1/users.
3. In the Headers tab, confirm whether Authorization is present. If you reference an environment variable such as {{apiToken}}, verify that the correct environment is selected in the environment dropdown.
4. Send the request.
5. Open the Response panel. Check the Status field and the response body. Many APIs return JSON such as {"error":"missing token"}.
6. Open the Request panel to confirm the outgoing Authorization header. If the header is absent or shows {{apiToken}} literally, the variable was not resolved.

If the header is present and correct but the server still returns 401, the cause is likely server-side: the token may be expired, lack the required scope, or be blocked by an IP restriction. If the header is missing or malformed, fix the request configuration or environment variable in Insomnia and resend.

Diagnostic Decision: Client or Server?

Limitations

The inspector shows the HTTP exchange as seen by the Insomnia client. It cannot reveal server-side processing, and very large response bodies may be truncated in the UI. Encrypted or binary responses appear as encoded data that you must decode outside Insomnia. Behavior can vary by Insomnia version, so confirm the inspector panels exist in your installed version before relying on them.

Practical Check

Send a GET request to https://example.com. Confirm the Response panel shows status 200, headers such as content-type, and a body. Then change the URL to an invalid path and confirm the status changes. If the panel does not update, make sure you are viewing the latest response in the request history.

Actionable Next Step

Next time an API call fails, open the Request and Response panels before changing application code. Compare the outgoing headers against the API documentation, then decide whether to fix the request in Insomnia or investigate the server.