Overview
A browser-based API inspector for sending HTTP requests and examining responses without a desktop client: pick a method, set headers and a body, send, and read back the status, timing, response headers, and body. Requests execute directly from your browser, subject to the same CORS rules as any web page.
How It Works
Choose GET, POST, PUT, PATCH, or DELETE and enter an absolute URL. Headers are authored as a JSON object (validated before sending, with clear errors for invalid JSON or non-string values) and the request body is a free-form field used for all methods except GET and DELETE. Press Send: the response panel shows the status code and text, round-trip duration in milliseconds, the full response header list, and the body — pretty-printed automatically when the content type is JSON. Your last request configuration is remembered for next time.
Step-by-Step Usage Guide
- Select the HTTP method and enter the absolute request URL.
- Add headers as a JSON object and a body for methods that take one.
- Press Send and read status, latency, headers, and the formatted body.
- Adjust and resend; the configuration persists between visits.
Technical Specifications & Standards
The tool uses the browser's fetch with an AbortController that aborts at 15 seconds and reports a clear timeout message rather than hanging. Because requests originate from the page, they carry your browser's origin, cookies subject to credentials policy, and — crucially — the browser's CORS enforcement: a missing Access-Control-Allow-Origin header on the target server surfaces as a caught error with a hint that CORS or network policy may be the cause, which is honest about why some APIs testable in Postman cannot be fetched from a web page. Response bodies identified as JSON are re-serialised with two-space indentation for readability; everything else renders as plain text. The request configuration (method, URL, headers, body) persists under the localStorage key CruxDev-client-api-tester-v1, but responses are deliberately not stored. The footer warning matters: requests run from your browser, not a server, so never paste production secrets into a client-side tool — anything typed here could be visible in the browser session.
Targeted Use Cases
- Debugging a webhook or REST endpoint while implementing its client.
- Checking whether an API's CORS headers allow browser access from your origin.
- Measuring response latency from your own network for a performance sanity check.
- Trying JSON-placeholder endpoints to demonstrate HTTP methods to a learner.
Notes & Gotchas
- Use test or sandbox endpoints with throwaway credentials — never paste production secrets.
- Expect CORS rejections on third-party APIs; they reflect the server's policy, not a tool bug.
- Send a body only for POST, PUT, or PATCH; GET and DELETE bodies are ignored here.
- Note the 15-second timeout and size your expectations for slow endpoints accordingly.
Frequently Asked Questions
Why does a request fail in this tool but work in Postman?
Requests here run from your browser and are subject to CORS. If the target API does not send the right Access-Control-Allow headers for this origin, the browser blocks reading the response. Desktop clients are not bound by CORS, which explains the difference.
How are request headers specified?
As a JSON object, for example { 'Accept': 'application/json' }. The tool validates the JSON before sending and reports specific errors for invalid syntax or non-string values.
What happens if a server is slow or unreachable?
The request is aborted after 15 seconds with an explicit timeout message. Network failures report the browser's error message plus a note that CORS or network policy may be involved.
Is my request history stored?
Only the most recent request configuration (method, URL, headers, body) is kept, under the localStorage key CruxDev-client-api-tester-v1. Responses are not stored, and nothing is sent to any server besides the API you target.