Skip to main content

Rate Limiting

Rate limiting controls how fast requests are sent during tests. Proper rate limit configuration prevents 429 (Too Many Requests) errors and ensures reliable data collection.

Test-Time Rate Limiting​

When running Full Collection or Iterate tests, you can configure per-endpoint rate limiting:

Configuration​

SettingDescriptionDefault
Delay between requests (delayMs)Milliseconds to wait between each request0 (no delay)
Respect Retry-After (respectRetryAfter)When receiving a 429 response, wait the time specified in the Retry-After header, then retrytrue

Where to Configure​

Rate limit settings are per-endpoint and configured in the endpoint's test panel:

  1. Select an endpoint
  2. Open the test configuration
  3. Set the delay and retry-after options
  4. Settings are saved with the connector test data

How It Works During Tests​

Delay Between Requests​

When delayMs is set, the test runner waits the specified time between each API request:

Request 1 → wait 500ms → Request 2 → wait 500ms → Request 3 → ...

During the wait, a persistent rate limit bar appears in the progress modal showing the countdown.

Respect Retry-After​

When enabled and the API returns a 429 response:

  1. The test reads the Retry-After header
  2. Waits the specified duration
  3. Retries the same request
  4. The rate limit bar shows the wait time

This is useful for APIs that provide explicit rate limit guidance.

Connector-Level Rate Limits​

Separately from test-time rate limiting, each endpoint can define production rate limits:

{
  "rateLimit": {
    "requests": 100,
    "windowSeconds": 60
  }
}

These limits are enforced during actual data collections (not during test runs). They define how many requests can be made within a time window.

See Endpoint Configuration for details.

Rate Limit Progress Bar​

During streaming tests (Full Collection and Iterate):

  • A persistent bar appears at the top of the progress modal when rate limiting is active
  • Shows the countdown timer for the current delay
  • Indicates whether the delay is from configured delayMs or a Retry-After response
  • Disappears when the next request begins

Finding the Right Delay​

Start Conservative​

Begin with a higher delay and reduce it:

  1. Start with 1000ms (1 second between requests)
  2. Run a test and check for 429 errors
  3. If no errors, try 500ms
  4. Keep reducing until you find the sweet spot

Check API Documentation​

Most APIs document their rate limits:

  • Requests per minute: Divide 60000 by the limit (e.g., 100 req/min = 600ms delay)
  • Requests per second: Use 1000ms / limit as the delay
  • Burst limits: Some APIs allow bursts — you may not need constant delays

Common Delay Values​

API Rate LimitSuggested Delay
1000 req/min60ms
100 req/min600ms
30 req/min2000ms
10 req/min6000ms

Best Practices​

  1. Always enable Respect Retry-After — It's the safest option for unknown rate limits
  2. Start with a delay for unfamiliar APIs — Better to be slow than to get blocked
  3. Monitor 429 responses — If you see them during tests, increase the delay
  4. Different endpoints may need different limits — Heavy endpoints may need longer delays than lightweight ones
  5. Account for iteration count — An iterate test with 100 values and 500ms delay takes ~50 seconds

Troubleshooting​

"Still getting 429 errors with delay configured"​

  • Increase the delay — the API's rate limit may be stricter than expected
  • Enable respectRetryAfter to automatically handle 429 responses
  • Check if the API has per-endpoint rate limits (some endpoints have lower limits)

"Test is very slow"​

  • The delay applies between every request
  • For iterate tests: total time ≈ iterations × (response time + delay)
  • Consider reducing the delay or testing with a subset of values first

"Rate limit bar not showing"​

  • The bar only appears when delayMs > 0 or when a 429 response is being waited out
  • Verify rate limit settings are saved (check the endpoint configuration)