Search DevTools

Jump to any tool or page

API Test Simulator

Simulate API requests through a proxy and measure latency, throughput, and failure rate.

Request

1 step
Scenario steps
Step 1
Headers
Authorization
Test settings

Response

Run the test to see results here.

How to use this tool

This API load testing simulator stress-tests and measures the performance of your API endpoints. It sends multiple requests in parallel through a proxy (to avoid CORS issues) and records response time, success rate, and failure rate.

  • Scenario Builder — define a sequence of API requests that simulate a user journey (login → fetch data → post data).
  • Method — HTTP method (GET, POST, PUT, DELETE).
  • URL — the API endpoint you want to call.
  • Request Body — JSON payload to send (for POST/PUT).
  • Concurrency — number of virtual users sending requests at the same time.
  • Duration — how long the test should run, in seconds.
  • Global Max RPS — limits total requests per second across all workers. Set 0 for unlimited speed.
  • Results panel — total requests sent, success/fail counts, average/min/max latency, and sample API responses.

Purpose

This tool helps you identify performance bottlenecks, ensure stability under high load, and detect issues like slow responses or request failures before pushing changes to production.

Example use cases

  • Simulating a login + data fetch + data update workflow for multiple users.
  • Stress testing a search API with 100 requests/sec.
  • Comparing API performance before and after code changes.
API Development

About API Test Simulator

Compose HTTP requests with custom methods, headers, and bodies, fire them, and inspect status, timing, and response payloads. Because the request originates from a browser page rather than a server, the same-origin policy and CORS apply — which is why some requests that succeed from curl fail here with no useful error detail.

Related API Development tools

Email ValidatorAPI to ModelsWebhook TesterPhone ValidatorOpenAPI Explorer

Frequently asked questions

Why does a request that works in curl fail in the browser?
curl is not bound by the same-origin policy. A cross-origin request from a page needs the server to return Access-Control-Allow-Origin covering the caller. Anything beyond a simple request — a custom header, a JSON content type, a PUT or DELETE — triggers a preflight OPTIONS the server must also answer with matching Allow-Methods and Allow-Headers. If it does not, the fetch rejects with an opaque network error; the actual reason appears only in the browser console, never in the response object.
Why can't I read the real status code on a failed cross-origin call?
When CORS blocks a response the browser hands JavaScript an opaque failure, not the HTTP status. A 401 and a 500 are indistinguishable, because exposing them would leak information about internal services to any page the user visits. The same restriction limits readable headers to the CORS-safelisted set unless the server names others in Access-Control-Expose-Headers — so Location on a 201 and X-RateLimit-Remaining are commonly invisible until the server opts in.
How should I read the timing numbers?
Wall-clock time around a fetch bundles DNS resolution, TCP and TLS handshake, request transmission, server processing, and download. A first call to a cold host can be hundreds of milliseconds of handshake alone, and the second call reuses the connection. Treat the first measurement as an outlier, and remember a preflight adds an entire extra round trip that the timing may or may not include. For server latency specifically, compare against a same-region measurement rather than a browser one.
What happens with redirects and cookies?
fetch follows redirects transparently by default, so a 301 chain reports only the final status, and you lose sight of intermediate hops. Cookies are not sent cross-origin unless credentials are included, and that in turn requires the server to send Access-Control-Allow-Credentials with a specific origin — the wildcard is rejected in credentialed mode. Cookies marked SameSite=Lax or Strict are withheld from cross-site requests regardless of what the CORS headers say.
Why do I get 401s on an endpoint whose token works elsewhere?
Common causes, in rough order of frequency: a trailing newline copied into the token value, a missing Bearer prefix, an expired exp claim measured in seconds not milliseconds, and a header name typo the server ignores silently. Signed-request APIs add another — HMAC schemes such as AWS SigV4 sign the canonical headers and body, so anything that alters the request after signing, including a proxy adding a header, invalidates the signature.