REST API Response & Latency Tester

How to Use It

1. Choose an HTTP method from the dropdown (GET, POST, PUT, DELETE, PATCH, HEAD).
2. Enter the full endpoint URL, e.g. https://api.example.com/v1/posts — if you omit the protocol, https:// is assumed automatically.
3. Optionally expand + Optional Request Headers & Body to add custom headers (one per line, Header: value) and, for POST/PUT/PATCH, a raw JSON request body.
4. Click Send Request and wait for the response — requests are capped at a 12-second timeout.
5. Read the status banner: the colored badge shows the exact status code (green for 2xx, blue for 3xx, red for 4xx/5xx), and the latency figure to its right is colored by speed threshold (green under 300ms, amber under 800ms, red above).
6. Check the four-cell stat grid for payload size, CORS status, remaining rate limit (if the API exposes it), and content type.
7. Scroll the Response Body panel to inspect the payload, and use Copy Body to grab it, or scan the Response Headers list for caching, security, or auth-related headers.

The Underlying Mechanism

HTTP status codes are grouped into ranges with distinct meaning: 2xx means the request succeeded (200 OK, 201 Created, 204 No Content); 3xx means the client should follow a redirect; 4xx means the client's request was invalid or unauthorized (400 Bad Request, 401 Unauthorized, 404 Not Found, 429 Too Many Requests); 5xx means the server itself failed while processing an otherwise-valid request. The status badge color in this tool follows that same 2xx/3xx/4xx-5xx grouping.

CORS (Cross-Origin Resource Sharing) governs whether client-side JavaScript running on one origin (say, your dashboard at app.example.com) is permitted to read a response from a different origin (api.example.com). The server signals permission via the Access-Control-Allow-Origin response header. This tool's check is a simple presence test on that header for GET-style requests — it does not simulate a full browser CORS preflight (the OPTIONS request browsers send automatically before certain cross-origin requests with custom headers or non-simple methods), so a header being present here doesn't guarantee every type of browser request will succeed against that endpoint.

Because the request originates from Nimbica's infrastructure rather than a visitor's browser, the latency figure reflects the network path and processing time between Nimbica's server and your API — DNS resolution, TLS handshake, server processing, and data transfer for that specific hop. It's a strong proxy for how fast your API itself responds, but a real visitor's total experience also depends on their own connection and geographic distance to your server.

Worked Example

Send a GET request to the public test API https://jsonplaceholder.typicode.com/posts/1 with no custom headers. This is a well-known, stable REST testing service that, per its documented API, returns a single JSON object with userId, id, title, and body fields for that path. You'd expect: status 200 OK, a Content-Type of application/json; charset=utf-8, a small payload (well under 1 KB), and a pretty-printed JSON body in the Response Body panel.

Compare that to sending an unauthenticated GET request to a real WooCommerce store's REST endpoint like /wp-json/wc/v3/orders. Because that endpoint requires OAuth or API-key authentication, you'd typically see a 401 Unauthorized status with a JSON error body describing the missing credentials — a genuinely useful result, since it confirms the endpoint exists and is reachable, and tells you exactly what authentication step is missing before you wire it into real client code.

Practical Use Cases

• Post-deploy API smoke tests: After updating a WooCommerce or custom WordPress REST endpoint, confirm it still returns 200 and the expected JSON shape before customers hit it.
• Webhook receiver validation: Confirm your own webhook-handling endpoint responds quickly (well under the 2-second window most senders expect) and with the correct status code.
• Pre-integration CORS checks: Before wiring a headless or decoupled frontend to a backend API, confirm the Access-Control-Allow-Origin header is present and matches expectations.
• Rate-limit awareness: Check whether a third-party API (payment gateway, shipping calculator, CRM) exposes remaining rate-limit headers so you can build retry logic that respects them.
• Auth header debugging: Confirm a Bearer token or API key is being accepted by checking whether the response flips from 401 to 200 once the correct Authorization header is attached.

Common Mistakes & Limitations

• Treating this latency as end-user latency: It measures Nimbica-server-to-API latency, not the experience of a visitor in a different region on a mobile connection.
• Malformed custom headers: A header line needs a colon separating name and value with content on both sides — a typo silently drops that header from the request instead of erroring.
• Testing internal or local URLs: The built-in SSRF protection blocks loopback addresses, private IP ranges, and cloud metadata endpoints, so you can't point this tool at localhost or an internal staging server on a private network.
• Hard 12-second timeout: A genuinely slow endpoint that would eventually respond in 15+ seconds will show as a failed request here, even though it might succeed for a client with a longer timeout configured.
• GET/HEAD requests ignore the body field: The request body textarea only applies to POST, PUT, and PATCH — content typed there is not sent with other methods.