Rate Limit Testing

Location: Sidebar → Rate Limit Testing

The Rate Limit Tester can be used to send any saved request a configurable number of times and reporting latency metrics in real time. The main purpose of this is to test when you have applied rate limit against users. For example, you may have a rate limit set against Anonymous users where they can only make 100 requests per minute. In this case, you can send 200 requests as an Anonymous user and ensure that responses are blocked after the 100th request.

The Rate Limit Tester can be used against any of the supported request types (Tables, RPC Functions, Edge Functions, Storage Buckets).

Configuration

Setting	Range	Description
Request	Any saved collection item	The request to load test.
Total requests	1 – 10,000	Total number of requests to send.
Concurrency	1 – 10	Number of simultaneous requests.

Running a Rate Limit Test

1. Select a saved request from the picker.
2. Set Total Requests and Concurrency.
3. If the request uses variables, enter test values in the Variables panel.
4. Click Start.

Real-Time Metrics

Metric	Description
Progress	Percentage of total requests completed.
Success count	Requests that completed without error.
Failure count	Requests that returned an error.
Average latency	Mean response time across all completed requests.
Min / Max latency	Fastest and slowest individual response times.
Latency distribution	Bar chart showing how response times are distributed.
HTTP Response Codes	Details the HTTP response codes recieved during test.
Response log	A scrollable log of the last 500 individual responses, with expandable details.

Auth Context Handling

For the Email User and Anonymous User contexts, the rate limit tester restores the session before the test begins. All requests in the run share the same session token.

Rate Limit Discovery

Rate limit testing is an effective way to discover rate limits. Ramp up request volume until 429 (Too Many Requests) responses appear in the log. The response log captures headers such as Retry-After and X-RateLimit-* so you can see exactly what limits are in place.

Authentication Rate Limit Tests

In addition to testing saved requests, the Rate Limit Tester includes four built-in authentication rate limit tests. These appear at the top of the "Request to test" dropdown under the Auth Rate Limits group and target Supabase GoTrue (Auth) endpoints that are rate-limited per IP address. These tests align with settings in the Authentication > Rate Limits page in the Supabase administration page.

Tip: The default limits shown below are Supabase platform defaults. Your project may have different configured limits — adjust the Number of Requests field accordingly.

Rate limit for token refreshes (Authentication)

Tests how many session token refreshes your IP can make before being throttled.

Detail	Value
Default limit	150 requests / 5 minutes
Expected responses	200 until limit is hit, then 429
Default requests	160
Concurrency	Locked to 1

How to use:

1. Select Rate limit for token refreshes (Authentication) from the dropdown.
2. Choose an auth context that has an active session — Anonymous User, Email User, or Custom JWT. The Publishable Key and Secret Key contexts do not produce sessions, so they cannot be used for this test.
3. Adjust Number of Requests if your project uses a non-default limit.
4. Click Start. Concurrency is locked to 1 because each request depends on the refresh token returned by the previous request.

Watch the response log for 429 responses — that's where the rate limit kicks in.

Rate limit for token verifications (Authentication)

Tests how many OTP or magic link verification attempts your IP can make before being throttled.

Detail	Value
Default limit	30 requests / 5 minutes
Expected responses	Usually gives error 403 (Token has expired or is invalid) until limit is hit, then 429
Default requests	35
Default concurrency	5

How to use:

1. Select Rate limit for token verifications (Authentication) from the dropdown.
2. The Authentication Context selector is hidden for this test — it uses only the project's publishable key.
3. Choose the OTP Type (Email or SMS) and enter the corresponding email address or phone number. These don't need to match a real pending OTP — the test sends deliberately invalid codes.
4. Adjust Number of Requests and Concurrency as needed.
5. Click Start.

The first ~30 requests will return 403 (Token has expired or is invalid). Once the rate limit is reached, responses switch to 429.

Rate limit for sign-ups and sign-ins (Authentication)

Tests how many credential-based sign-in or sign-up attempts your IP can make before being throttled. This covers signInWithPassword, signUp, and similar flows (excluding anonymous users).

Detail	Value
Default limit	30 requests / 5 minutes
Expected responses	400 (Invalid login credentials) until limit is hit, then 429
Default requests	35
Default concurrency	5

How to use:

1. Select Rate limit for sign-ups and sign-ins (Authentication) from the dropdown.
2. The Authentication Context selector is hidden — this test uses only the publishable key.
3. Enter the Email address to attempt sign-in with. Any real or non-existent email works; every attempt counts against the IP rate limit.
4. Adjust Number of Requests and Concurrency as needed.
5. Click Start.

The test uses a deliberately incorrect password. Expect 400 responses until the rate limit triggers 429 responses.

Note: If your project has CAPTCHA enabled for sign-in, all requests will be rejected (422). Disable CAPTCHA in your Supabase dashboard before running this test.

Rate limit for anonymous users (Authentication)

Tests how many anonymous sign-ins your IP can create before being throttled.

Detail	Value
Default limit	30 requests / hour
Expected responses	200 until limit is hit, then 429
Default requests	35
Default concurrency	5

How to use:

1. Select Rate limit for anonymous users (Authentication) from the dropdown.
2. The Authentication Context selector is hidden — anonymous sign-in always uses the publishable key.
3. Adjust Number of Requests and Concurrency as needed.
4. Click Start.

Each successful request creates a new anonymous user in auth.users. Clean up these users via the Supabase dashboard after testing.

Note: If your project has CAPTCHA enabled for sign-up, all requests will be rejected unless CAPTCHA is disabled first.

---