API Tester

In-Depth Guide

An API tester is a lightweight curl with a UI: you compose an HTTP request — method, URL, headers, body — fire it, and inspect the full response including status code, headers, timing, and body with syntax highlighting. Unlike Postman or Insomnia, an in-browser tester has no account, no cloud sync, and no background telemetry. Requests go directly from your tab to the target endpoint via the Fetch API per the WHATWG Fetch Standard, subject to CORS. The tool handles bearer tokens, basic auth, cookies (same-origin only, per browser security), multipart file uploads, and URL-encoded form bodies. Response previews cover JSON (with collapsible tree), XML, HTML, images, and binary hexdump. Nothing leaves the browser other than the request itself, which is the point — testing your own authenticated API should not require handing the credentials to a SaaS tool.

Why This Matters

Every engineer debugging a webhook, integrating a third-party service, or building an internal endpoint hits HTTP testing. curl is universal but cryptic: curl -X POST -H "Authorization: Bearer ..." -d '{...}' ... is fine for one request, unbearable for thirty. Postman has a UI but requires sign-up and pipes every request history to its backend. A browser-local tester fills the gap — fast enough to iterate, private enough to use with production tokens, featureful enough to inspect real payloads, and free of any external dependency.

Real-World Case Studies

• Webhook verification. A payments engineer is testing a Stripe webhook integration. She pastes the Stripe stripe_signature header into the tester, fires the request, and confirms the backend returns 200. Reproducing the failing case with a mangled signature produces the expected 400 with the right error message — a confirmation loop that would take twenty minutes over shell and curl, compressed into two minutes.
• Rate-limit discovery. A DevRel engineer writing a tutorial needs exact rate-limit headers from a third-party API. He fires 50 requests in the tester, watches the X-RateLimit-Remaining counter drop, and records the exact reset behaviour. The resulting blog post has authoritative numbers rather than hand-waved estimates, and the tester's request history gives him a copy-paste audit trail for his editor.
• Incident triage. An SRE paged at 03:00 about a failing health endpoint needs to know whether the problem is the endpoint, the TLS certificate, or the DNS. The tester fires a request, shows a clean 200 from a specific IP, and the response time histogram makes it clear the slowness is downstream of the endpoint, not at it. The root cause is a database connection pool, not an HTTP bug, and the page resolves without a full rollout.

Technical Deep Dive

The tester uses fetch(url, {method, headers, body, credentials}) per the WHATWG Fetch Standard. CORS matters: requests to a different origin without an Access-Control-Allow-Origin response header fail at the browser layer, which is a feature rather than a bug — it prevents web pages from becoming ambient SSRF clients that pivot into internal networks. For same-origin requests and any endpoint that opts into CORS, everything works including credentials when credentials: 'include' is set. Request timing uses performance.now() around the await, accurate to sub-millisecond resolution, and response size is measured via the Content-Length header or by buffering the response body when the header is absent (streaming responses). Binary responses are displayed as Uint8Array hexdump with ASCII sidebar, mirroring the classic xxd output. The tester recognises status code classes (1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error) per RFC 9110 and colour-codes accordingly, with specific recognition for common codes like 401, 403, 429, and 503 that carry meaning beyond their class. Saved requests are stored in localStorage as a versioned JSON blob for later replay, with a size cap to avoid filling the quota.