Application Programming Interface (API) Testing Tool

Request snapshot

Request target:

Enter a full https:// URL or paste cURL; query rows below are merged into the final request.

Browser-side runner CORS must allow your origin or the browser will block the response. Paste a full URL or cURL command to seed the request builder.

Request options

Tabbed builder

5 tabs

Query parameters:

Use one row per query pair, e.g. limit=10; switch rows off to keep them without sending.

On	Key	Value	Remove

Headers:

Use one row per header, e.g. Accept: application/json; leave browser-managed headers out.

On	Header	Value	Remove

Auth type:

Choose Basic or Bearer only when this endpoint expects Authorization.

Basic credentials:

Credentials apply to this run and stay out of saved presets unless you opt in.

Username:

Example: alice or sandbox-client.

Password:

Paste the secret value only; it is not displayed in the field.

{{ showBasicPassword ? 'Password is visible.' : 'Password is hidden.' }}

Bearer token:

Paste only the token; do not include the Bearer prefix.

{{ showBearerToken ? 'Bearer token is visible.' : 'Bearer token is hidden.' }}

Body mode:

GET/HEAD ignore body; JSON, form, and multipart prepare different payload shapes.

Request body:

Use JSON text such as {"name":"Ada"}, or raw content for custom media types.

Form fields:

Use field names such as email with values such as ada@example.com; disabled rows are not sent.

On	Key	Value	Remove

Multipart parts:

Use file rows for uploads; saved presets remember names but files must be reattached.

On	Key	Type	Value / File	Remove
			Selected: {{ row.file.name }} Reattach file: {{ row.savedFileName }}

GET and HEAD send no body; JSON/form set Content-Type when needed, multipart lets the browser set the boundary.

Timeout:

Use 9000 for normal tests; raise for slow APIs or set 0 to wait indefinitely.

Redirects:

Use manual when checking Location headers; follow matches normal browser fetch behavior.

Credentials:

same-origin is safest; include sends cookies when CORS allows credentials.

Cache:

Use no-store for fresh API debugging; default follows browser cache rules.

Parse cURL:

Paste one cURL command, then Parse to populate the request builder.

The Request target box also accepts cURL when you paste a full command there.

Metric	Value	Copy
{{ row.label }}	{{ row.value }}
No response metrics.

{{ formattedBody }}

Preview is available only for HTML responses.

Provide a URL or parse an incoming cURL command to populate the request trace.

Send a request to capture the response trace with status line, headers, body, and timing.

Header	Value	Copy
{{ h.key }}	{{ h.value }}
No headers returned.

Recent runs

Browser-local request history

Only the method, target, status, timing, and content-type are retained here. Load any target back into the editor to retry it.

Captured	Method	URL	Result	Actions
	{{ entry.method }}	{{ entry.url }}	· {{ entry.elapsedMs }} ms · {{ entry.responseType }}
No recent runs yet.

Saved requests

Stored request presets

Requests stay in your browser. Blank request names auto-label from the current method and target.

Save label:

Example: Sandbox POST users.

Include auth in presets:

Keep off for shareable presets; turn on only for private browser-local reuse.

Import JSON

Name	Method	URL	Actions
{{ entry.name }}	{{ entry.method }}	{{ entry.url }}
No saved requests yet.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

HTTP API testing means sending a precise request and reading the response as evidence. The request has a method, URL, query values, headers, credentials, body, timeout, redirect behavior, cache choice, and credential policy. The response has a status, exposed headers, a body, a final URL, and timing.

A browser API test answers a narrower question than a terminal request: what can frontend code send and read from this origin? That distinction matters when a request succeeds in a command-line client but fails in the browser because Cross-Origin Resource Sharing (CORS), redirects, credentials, or exposed headers block the response details.

Browser API request path from request setup through CORS to response evidence — A browser request can record HTTP evidence only when browser policy lets the page read it.

Good API debugging separates server evidence from browser visibility. A 401 response, a JSON validation failure, a timeout, and a CORS block all call for different fixes. Keeping the request settings and the response evidence together makes the next report easier to reproduce.

Authentication needs extra care. Basic credentials are encoded for transport, not encrypted by the scheme itself, and bearer tokens can be used by anyone who holds them until the server rejects them. Use sandbox credentials when possible and keep reusable presets without secrets unless the preset is strictly private to the current browser.

How to Use This Tool:

Build the request from the top down, then read the summary before opening the detailed response tabs.

Choose a recipe or keep the blank request, then set the method and Request target. The snapshot should show the intended method and host before anything is sent.
Use Query and Headers for enabled rows only. Keep filters visible as query rows when you want a clean record of the final URL.
Select Auth only when the endpoint expects it. Use Basic for username-and-password style requests and Bearer for access tokens without typing the word Bearer into the token field.
Choose the correct Body mode for non-GET and non-HEAD requests. JSON mode checks the body before sending, form mode sends enabled key-value rows, and multipart mode can include text or file parts.
Open Transport when timeout, redirect mode, credentials, cache behavior, cURL import, or copyable request snippets matter. If a pasted cURL command imports incorrectly, read the request trace before sending.
Send the request and check the response snapshot first. It summarizes status, success, elapsed time, body size, content type, final URL, charset, and body classification.
Use the result tabs for the job at hand: body text for raw evidence, JSON for parsed data, HTML preview for HTML replies, headers for exposed response metadata, traces for handoff notes, and exchange JSON for a structured record.

Interpreting Results:

Start with the status and failure class, then confirm the body and final URL. A fast response is not automatically correct if the final URL changed or the content type does not match the API contract.

API test result cues and recommended follow-up checks
Cue	What it usually means	What to check next
`2xx`	The browser received a successful HTTP response.	Verify the body shape, content type, and final URL before marking the endpoint healthy.
`3xx`	Redirect handling affected the visible result.	Use manual redirect mode when the redirect target itself is the evidence you need.
`4xx`	The server rejected the request for a client-side reason such as auth, validation, or route mismatch.	Compare the request trace against the API docs before changing the response parsing.
`5xx`	The server reported a failure while handling the request.	Keep the method, URL, body, status, and response trace together for server-log review.
Status `0`	The browser did not expose a normal HTTP response because of timeout, cancellation, transport failure, or CORS blocking.	Read the failure text and compare with a CORS-enabled endpoint or a terminal request when server reachability is in doubt.

JSON classification means the content type includes JSON or the body text parses as JSON. HTML preview appears only for HTML-like responses. Binary-looking responses are summarized by size instead of being forced into a text view.

Saved requests and recent runs are browser-local conveniences. Recent runs keep a compact history of request outcome details, while saved presets omit credentials unless Include auth in presets is switched on.

Technical Details:

HTTP semantics separate the request method from the payload. GET and HEAD are retrieval-style methods, so a body is not sent for those methods here. POST, PUT, PATCH, and DELETE can carry payloads, but the server still defines how each endpoint treats them.

Browser Fetch adds policy checks around the HTTP exchange. Credentials, redirects, cache mode, timeout cancellation, and CORS can all change what is visible to page code. A server can receive a request while the browser still refuses to expose the response body or headers to the page.

Formula Core:

The response time shown in the result is an elapsed browser measurement for one attempt. It is not a server-only processing time.

t_{elapsed} = t_{finish} - t_{start}

t_start is the browser timestamp just before the request attempt, and t_finish is the timestamp after the response body is read or the run ends with a timeout, cancellation, or transport failure. Body size is measured from the returned body bytes that the browser can read.

Request Construction Rules:

How API request settings affect the outgoing browser request
Part	Rule	Why it matters
URL and query rows	Enabled query pairs are appended to the target URL, with duplicate pairs skipped when they already exist.	The final URL remains readable while still carrying visible filters such as page, limit, or search terms.
Headers	Enabled header rows are sent, then Basic or Bearer auth can add an `Authorization` header.	A missing or stale credential usually appears as `401` or `403`, not as a JSON parsing problem.
JSON body	JSON is validated before sending and normalized when valid. A JSON content type is added when none is already present.	Invalid JSON stops the run before the request is sent.
Form body	Enabled key-value rows are encoded as URL-encoded form data.	This matches many token, login, and legacy form endpoints.
Multipart body	Enabled text and file parts are sent as multipart form data, with the browser supplying the multipart boundary.	Manual boundary headers should not be forced for browser file-style uploads.

Browser Visibility Rules:

Browser visibility rules for API response testing
Condition	Visible result	Practical consequence
CORS allows the origin and exposes the needed response details	Status, permitted headers, and body are available to the result views.	The browser result is a good proxy for what frontend code can read.
CORS blocks the response	The run fails without a normal exposed HTTP response.	The endpoint may still be reachable from a terminal or server-side client.
Timeout expires before a readable response arrives	The request is aborted and marked as timed out.	Raise the timeout only after confirming the URL, method, body, and expected server latency.
Manual redirect mode is selected	Redirect evidence can be limited by browser security rules.	Use a terminal comparison when complete redirect headers are required.

Privacy and Safety Notes:

Requests are sent to the target URL you enter. If you test a private API, the target server can receive the method, URL, headers, credentials, and body you provide. Avoid production tokens in shared examples and remove sensitive headers before copying traces into tickets.

Browser-local presets and recent runs are still local records. Saved auth requires an explicit opt-in, but a private browser profile is still the safer place for credentialed API debugging.

Worked Examples:

Check a JSON list endpoint

Use GET, enter the endpoint URL, add query rows such as limit=10 and active=true, and keep Accept: application/json. A useful result shows 2xx, JSON classification, and a final URL containing the expected query values.

If the body is an error object even though the status is successful, the HTTP exchange completed but the API contract still needs review.

Rebuild a failing POST from cURL

Paste a command that includes a method, URL, content type, bearer token, and JSON body. Confirm the method, auth mode, body mode, and request trace before sending. If the response returns 401, the trace helps separate token validity from request formatting.

If JSON validation fails before sending, fix the body text first. Retrying the same invalid body will not reach the endpoint.

Separate CORS from server failure

A private endpoint can work from a terminal and still fail in the browser with status 0. Retry a known CORS-enabled test endpoint with the same browser, then compare. If the simple endpoint works, the likely issue is browser visibility policy rather than a completely unreachable server.

FAQ:

Why does the request work in cURL but fail here?

The browser applies CORS, credential, redirect, and exposed-header rules. cURL is not bound by those browser visibility policies.

Why is my JSON body rejected before the request is sent?

JSON body mode requires valid JSON. Fix the syntax or switch to raw body mode if the endpoint intentionally expects non-JSON text.

Can I test file uploads?

Yes. Use multipart form data, choose a file part, and let the browser supply the multipart boundary.

Does a success badge mean the API is healthy?

No. It means the status is in the HTTP success range. Check the body, content type, final URL, and expected fields before treating the endpoint as healthy.

What should I save for a bug report?

Save the request trace, response trace, status, final URL, content type, and any response body needed to reproduce the issue. Remove secrets first.

Glossary:

CORS: A browser security protocol that controls whether page code can read a cross-origin response.
Bearer token: An access token sent with the Authorization: Bearer scheme.
Content-Type: The header that names the media type of a request or response body, such as JSON, HTML, or plain text.
Redirect mode: The browser setting that decides whether redirects are followed, rejected, or handled manually.
Response trace: A readable record of exposed response status, headers, body text, timing, URL, and success state.

References:

RFC 9110: HTTP Semantics, RFC Editor.
Fetch Standard, WHATWG.
Using the Fetch API, MDN Web Docs.
RFC 7617: The Basic HTTP Authentication Scheme, RFC Editor.
RFC 6750: OAuth 2.0 Bearer Token Usage, RFC Editor.