Debug REST APIs end-to-end
When an API call fails in staging or production, the fastest path to a fix is not guessing — it is reproducing the exact request, reading the response body carefully, and isolating whether the problem lives in auth, payload shape, or server logic. This guide walks through a repeatable debugging workflow using SlashGit's browser-based dev tools. No local install, no Postman license — just open a tab and work through the steps in order.
Step 1: Reproduce the failing request
Start in the API Tester. Paste the endpoint URL, choose the HTTP method, and add headers exactly as your client sends them. Common mistakes hide in small details: a missing Content-Type: application/json, a trailing slash on the path, or an Authorization header with an extra space before the Bearer token.
If the failure only happens for certain users, capture a real request from browser DevTools (Network tab → right-click → Copy as cURL) and translate those headers into the tester. Run the request and note three things: status code, response time, and whether the body is JSON, HTML, or empty. A 401 with an HTML login page usually means you hit the wrong host or lost the auth header entirely.
Step 2: Format and validate the response body
Raw JSON returned as a single line is painful to scan. Copy the response into the JSON Formatter to prettify it and catch syntax errors early. If the formatter reports invalid JSON, the server may be returning an error page, a truncated stream, or double-encoded content — all useful clues.
Compare the formatted output against your API contract or OpenAPI spec. Look for renamed fields, null values where you expected arrays, and nested objects that changed shape after a deploy. When two environments disagree, format both responses side by side and diff them manually field by field.
Step 3: Inspect JWT and auth tokens
Many REST failures trace back to expired or malformed tokens. If your API uses Bearer JWTs, paste the token (without the Bearer prefix) into the JWT Decoder. Check the exp claim first — clock skew between client and server can cause intermittent 401s that look random.
Verify issuer (iss), audience (aud), and custom claims like role or tenant_id. A token that decodes fine but lacks the claim your middleware expects will pass signature validation yet still fail authorization. Never paste production tokens into public channels; use the decoder locally in your browser and discard the tab when done.
Step 4: Validate request payloads and encoding
When POST or PUT bodies fail validation, paste your draft JSON into the formatter before sending it through the API Tester. Typos in field names are the most common 400 cause. For endpoints that expect Base64-encoded blobs (file uploads, webhook signatures), use the Base64 Encoder to verify encode/decode round-trips without writing a script.
If error messages mention pattern mismatches — email format, slug rules, phone numbers — test your regex in the Regex Tester against the exact strings your client submits. A passing unit test in isolation does not help if the API applies a stricter pattern server-side.
Step 5: Document and close the loop
Once you find the root cause, save the working request configuration from the API Tester as a reference for your team. Write a one-line summary: what broke, what fixed it, and which environment was affected. For regressions, add an integration test that mirrors the reproduced request so the same bug cannot ship twice.
This five-step loop — reproduce, format, decode, validate, document — handles the majority of REST debugging sessions. Keep these tools bookmarked as a kit: API Tester, JSON Formatter, JWT Decoder, Base64 Encoder, and Regex Tester. Together they replace a scattered toolchain with one focused workflow.