Rate Limiting & Quotas

Overview

To maintain the stability and performance of the Supervised AI platform, the testing-api enforces rate limiting and usage quotas. These limits prevent resource exhaustion and ensure equitable access for all developers using the testing infrastructure.

Limits are applied based on the API Key associated with the request. If you exceed these limits, the API will temporarily reject further requests.

Rate Limit Headers

Every response from the testing-api includes standard HTTP headers to help you track your current usage and remain within established thresholds.

| Header | Description | | :--- | :--- | | X-RateLimit-Limit | The maximum number of requests allowed within the current window. | | X-RateLimit-Remaining | The number of requests remaining in the current window. | | X-RateLimit-Reset | The time (in UTC epoch seconds) when the current rate limit window resets. |

Default Quotas

The testing environment is subject to different quotas depending on your account tier. These limits apply specifically to the execution of test suites and data ingestion via the API.

Standard Testing Limits

• Requests per minute (RPM): 60 requests
• Requests per day (RPD): 10,000 requests
• Concurrent Test Executions: 5 simultaneous threads

Note: These limits are subject to change based on platform demand. For high-volume automated load testing, please contact the Supervised AI platform team to request a temporary quota increase.

Error Handling

When a rate limit is exceeded, the API returns a 429 Too Many Requests status code. The response body will contain a machine-readable error message and the time you can resume making requests.

Example Error Response

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "You have exceeded your request quota. Please try again in 45 seconds.",
    "retry_after_seconds": 45
  }
}

Best Practices

To avoid service interruptions, we recommend implementing the following strategies in your testing client:

Exponential Backoff

If your application receives a 429 error, do not retry the request immediately. Use an exponential backoff strategy (e.g., doubling the wait time between each retry) to allow the rate limit window to reset.

Request Throttling

Incorporate client-side throttling to match the API's RPM limit. This is particularly important when running large batches of automated tests or CI/CD pipelines.

Header Monitoring

Programmatically monitor the X-RateLimit-Remaining header. If the value drops below 10%, consider pausing non-critical testing operations until the X-RateLimit-Reset time is reached.