API Endpoint Checker

The request goes directly from your browser to the endpoint, not through our server. CORS applies. Cookies are omitted. In funnel mode, inputs are kept temporarily in this tab until step 2 loads, then removed from session storage. The endpoint still receives the URL, headers, body and your IP address.

Paste an HTTP or HTTPS URL and the tool sends a GET, HEAD, POST, PUT, PATCH or DELETE request directly from your browser. It reports the final status, time to response headers, response headers exposed by CORS, the final URL after a redirect and up to 1 MiB of the body. The endpoint must permit your browser origin through CORS for the response to be readable.

How to check an API endpoint

  1. 1

    Enter the URL

    Include the scheme (http:// or https://). The tool follows redirects by default.

  2. 2

    Choose HTTP method

    GET is the default. Switch to HEAD for a lighter check, POST/PUT/PATCH with a body for write-endpoint testing.

  3. 3

    Add headers if needed

    Authorization, Accept, Content-Type and custom headers can be set. Useful for testing API key auth or content negotiation.

  4. 4

    Inspect the browser-visible result

    Review the final status, elapsed time, CORS-exposed headers, final URL after a redirect and a body preview limited to 1 MiB.

HTTP status code reference

Code Meaning Action
200 OK Success
201 Created POST/PUT produced a resource
204 No Content Success with no body
301 Moved Permanently Follow redirect, update links
302 Found (temporary redirect) Follow redirect
304 Not Modified Cached copy still valid
400 Bad Request Fix the request
401 Unauthorized Missing or invalid credentials
403 Forbidden Authed but not allowed
404 Not Found Wrong URL or resource gone
429 Too Many Requests Back off, respect rate limit
500 Internal Server Error Server bug
502 Bad Gateway Upstream is down
503 Service Unavailable Maintenance or overloaded
504 Gateway Timeout Upstream did not respond in time

Response time benchmarks

Response time Perception
Under 100 ms Instant
100-300 ms Fast
300-1000 ms Acceptable
1-3 seconds Slow, users notice
Over 3 seconds Investigate for interactive use

These are rough diagnostic bands, not universal pass/fail limits. If an API has an SLA, compare repeated samples with its stated p95 and p99 targets.

Common headers worth inspecting

  • Content-Type, application/json; charset=utf-8 vs. text/html tells you what you’re actually getting.
  • Cache-Control, max-age=3600, public vs. no-store determines whether CDN and browser caches will hit.
  • Access-Control-Allow-Origin, for CORS debugging. Must be * or explicitly the requesting origin.
  • Strict-Transport-Security, HSTS presence confirms HTTPS-only enforcement.
  • X-RateLimit-Remaining, many APIs publish remaining quota per response.

What a browser request cannot reveal

  • Fetch follows permitted redirects and exposes the final URL, but not the complete redirect chain.
  • The browser validates HTTPS during the connection but does not expose certificate issuer, expiry or chain details to page JavaScript.
  • CORS decides whether this page can read the status, body and most headers. A CORS failure does not prove the API is down.
  • Browsers control headers such as Host, Origin, Cookie, Content-Length and User-Agent; this tool rejects those names instead of pretending to send them.

Frequently Asked Questions

Fetch follows redirects and exposes the final response and final URL, not each hop. This tool also omits browser cookies, and an API can vary its response by cookies, origin or other browser-controlled headers.

Yes, when the endpoint allows the resulting CORS request. Authorization values are sent directly to that endpoint. In funnel mode the fields are held temporarily in this tab only until step 2 loads, then removed from session storage; they never pass through our server. Avoid using production secrets on endpoints you do not trust.

The timer runs in your browser from just before Fetch begins until response headers arrive. It includes browser and network overhead, while server logs often report application processing only. It does not include downloading the body, so compare repeated checks from the same browser and network.

No. This checker uses browser Fetch for ordinary HTTP and HTTPS requests. WebSocket and gRPC require protocol-aware clients and are not tested here.

Related Tools