HTTP Request — Take the Browser Out of the Equation
This sends an HTTP request you control completely and shows the unmodified response. The browser is doing a great deal on your behalf — adding headers, following redirects, applying CORS rules, using a cached copy, retrying — and any of those can be the thing that is actually happening. Removing the browser is how you find out.
When it helps
It answers the question every front-end bug starts with: is this my code or the API? A fetch that fails in the browser and succeeds here means the request is fine and something in the browser's rules rejected it — usually cross-origin policy, occasionally a cached preflight. A request that fails here too means the API is genuinely returning what it returns, and you can stop reading your own code. That fork is worth two minutes at the start of any investigation.
Worth running automatically
The endpoints your front end depends on are worth checking on their own schedule, independently of whether anyone is using the app. An API that starts returning a different shape breaks your build or your runtime with no warning, and because the status code is still 200, nothing in a conventional uptime check notices. Asserting on the response body — that a field exists, that a value is the expected type — is what turns a silent contract change into an alert.
What you get out of it
Splits a bug into client or server in one step, which is the most valuable two minutes in any front-end investigation. Scheduled, it watches the API contract your code is written against.