Developer Tool

API Rate Limit Tester

Send controlled bursts of requests to any API endpoint and analyze rate limiting, response times, and throughput.

Browser CORS notice: Browsers block cross-origin requests unless the API responds with Access-Control-Allow-Origin headers. If you get network errors, use the CORS Proxy URL field in the configuration below — enter https://corsproxy.io/?url= to route requests through a free public proxy that adds the required headers.

Status

Test progress

Configure your test settings and click Start Test.

See Digia Engage in action

Turn every app session into activation, retention, and revenue.

Get a Demo

Highlights

What this tool does

  • Sends up to 1,000 HTTP requests at configurable concurrency levels to reveal rate limit thresholds and server behavior under load.
  • Tracks 429 Too Many Requests responses separately from other failures, so you can pinpoint the exact volume at which the API begins rate limiting.
  • Reports average, minimum, and maximum response times alongside requests per second — the key metrics for understanding API performance under concurrent load.
  • Supports all common HTTP methods (GET, POST, PUT, PATCH, DELETE) with dynamic request headers and a JSON body editor.
  • Exports full results as JSON or CSV for sharing with your team or archiving alongside API integration documentation.
  • Runs entirely in your browser — your API credentials, URLs, and request data never leave your device.

How To

How to use this tool

  1. 1. Enter the API endpoint URL: Paste the full URL of the API endpoint you want to test, including the protocol (https://). Make sure the API allows cross-origin requests from a browser, or test an endpoint you control.
  2. 2. Select the HTTP method and configure headers: Choose the HTTP method (GET, POST, PUT, PATCH, or DELETE). Add any required request headers such as Authorization or Content-Type using the Add Header button. For POST/PUT/PATCH, enter a valid JSON body.
  3. 3. Set concurrency and request count: Set how many total requests to send (1–1000) and how many to run simultaneously (1–100). Start with lower values to understand baseline behavior before ramping up.
  4. 4. Click Start Test and observe results: Click Start Test. Results update in real time as requests complete. Watch for 429 responses in the status code breakdown — they indicate the rate limit threshold has been reached.
  5. 5. Export or copy the results: After the test completes, use Copy Results, Export JSON, or Export CSV to save the full request log for further analysis or documentation.

Concept

What is API rate limiting?

API rate limiting is a technique used by API providers to control how often a client can call an endpoint within a defined time window. Common windows are per second, per minute, per hour, or per day. When a client exceeds the limit, the server returns an HTTP 429 Too Many Requests response, often with a Retry-After header specifying when to try again.

Rate limits protect API infrastructure from overload, prevent abuse, and enforce fair usage across all clients. For developers building integrations, understanding an API's rate limits is essential for designing reliable retry logic, request queuing, and backoff strategies.

Request-count limits

The most common form. The API allows N requests per time window. Exceeding that count triggers a 429 until the window resets.

Concurrency limits

Some APIs limit how many requests can be in-flight simultaneously, regardless of total volume. Excess concurrent requests are queued or rejected.

Burst vs. sustained limits

APIs often allow short bursts above the sustained rate. Token bucket and leaky bucket algorithms are common implementations for this behavior.

Common Use Cases

When to use this tool

Rate limit discovery

Find the exact request-per-second or request-per-minute threshold at which an API starts returning 429 errors, so you can design your integration to stay within limits.

Concurrency stress testing

Identify how an API behaves under simultaneous requests — whether it queues, drops, or throttles connections — before scaling your application.

Performance benchmarking

Measure average, minimum, and maximum response times at different load levels to establish baselines and spot latency degradation under load.

Retry strategy validation

Confirm that your retry and backoff logic matches real-world API behavior by observing 429 frequency and distribution across a burst of requests.

API gateway testing

Test rate limits configured in API gateways (Kong, AWS API Gateway, Nginx) before deploying to production to verify that gateway rules behave as expected.

Third-party integration planning

Before building integrations with third-party APIs, understand their practical rate limits and latency characteristics under realistic concurrent usage.

How It Works

Understanding the metrics

Metric What it measures Why it matters
429 Count Requests rejected with HTTP 429 Shows where the rate limit ceiling kicks in
Success Rate % of requests returning 2xx Overall measure of how well the API handles the load
Avg Time Mean response latency in ms Baseline for expected API performance
Req / sec Completed requests per second Your effective throughput at the configured concurrency
Slowest Maximum single-request latency Indicates tail latency — worst case a user might experience

FAQ

Frequently asked questions

What is an API rate limit?

An API rate limit is a restriction on how many requests a client can make within a given time window. APIs enforce rate limits to protect infrastructure, ensure fair usage, and prevent abuse. When a client exceeds the limit, the server typically responds with an HTTP 429 Too Many Requests status code.

What does HTTP 429 mean?

HTTP 429 Too Many Requests indicates that the client has sent more requests than the server allows in a given time period. The response often includes a Retry-After header specifying when the client can try again. This tool counts 429 responses to help you identify at what request rate the API begins rate limiting.

How does concurrency affect rate limit testing?

Concurrency determines how many requests are in flight simultaneously. Higher concurrency means more requests hit the server in a shorter window, which can trigger rate limits sooner. Testing at different concurrency levels reveals whether limits are based on total request volume per time window or on concurrent connection count.

Why do some requests show network errors instead of status codes?

Network errors occur when the browser cannot complete the HTTP connection. Common causes include: CORS restrictions (the API does not allow cross-origin requests from a browser), DNS failures, SSL/TLS certificate errors, or the server being unreachable. CORS is the most common cause when testing APIs that were not designed for direct browser access.

What is CORS and why does it affect this tool?

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that blocks requests from one origin (like this page) to a different origin (like your API) unless the API explicitly allows it via Access-Control-Allow-Origin headers. Server-side tools and curl are not affected by CORS. To bypass CORS in testing, run this tool against APIs you control that have permissive CORS headers, or use a CORS proxy.

What is the difference between rate limiting and throttling?

Rate limiting enforces a hard cap — once exceeded, requests are rejected with 429. Throttling slows requests down rather than rejecting them, introducing artificial delays. Many APIs use both: throttling at normal load and hard limits at extreme load. This tool identifies the point where hard limits kick in by tracking 429 responses.

What does 'requests per second' (RPS) mean in the results?

Requests per second (RPS) is the total number of completed requests divided by the elapsed test time in seconds. It measures your effective throughput under the configured concurrency and delay settings. A high RPS with many 429 responses suggests you are hitting the rate limit ceiling of the API.

How do I find the exact rate limit of an API?

Start with a low number of requests and low concurrency. Gradually increase both until you see 429 responses appear. The request count or RPS at which 429s begin indicates the rate limit threshold. Also check the API's documentation and response headers — many APIs include rate limit info in X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After headers.

Is this tool safe to use on production APIs?

Only test APIs you own or have explicit permission to test. Sending many rapid requests to a production API without authorization may violate the API's terms of service, trigger security alerts, or temporarily block your IP address. Use staging or development environments when possible.

Does this tool store my API URL or headers?

No. All configuration and request execution happens entirely in your browser. No input is sent to Digia servers. Your API URL, headers, and request body never leave your device.

TL;DR

Quick summary

This free API Rate Limit Tester sends up to 1,000 HTTP requests to any endpoint with configurable concurrency, delay, and per-request timeout — all from your browser. Track successful responses, 429 rate-limit rejections, average and tail latency, and requests per second in real time. Export results as JSON or CSV for your records. The tool is read-only on our servers — your API URLs, headers, and credentials never leave your device. Only test APIs you own or have explicit permission to test.

  • Free to use
  • No signup required
  • All processing in-browser
  • No data sent to servers
  • Up to 1000 requests
  • Up to 100 concurrent
  • Export JSON & CSV
· · Last reviewed: June 2026 · All request execution uses the browser Fetch API. No data is sent to Digia servers.