Guide
Rate limits
Limits protect the service for everyone. They are generous for normal integrations; if you need more requests per minute, ask and we will raise that limit for your account.
Default limits
| Limit | Default |
|---|---|
| Requests per minute, per account | 600 |
| Tasks per POST request | 100 |
| Tasks per minute, per account | 2,000 |
| Tasks per live request | 1 |
| Access requests per hour, per IP address | 5 |
Your current limits are returned by user_data in rate_limits. Limits are counted per account across all of its keys, in fixed one-minute windows. The requests-per-minute limit is set per account and can be raised on request; the task limits (per POST request and per minute) are the same for every account.
Rate-limit headers
Every authenticated response carries the state of your current window:
| Header | Meaning |
|---|---|
| X-RateLimit-Limit | Requests allowed per minute for your account. |
| X-RateLimit-Remaining | Requests left in the current window. |
| X-RateLimit-Reset | When the current window resets (Unix time in seconds). |
| Retry-After | Only on 429 responses: seconds to wait before retrying. |
When you hit a limit
The request is rejected with HTTP 429, status code 40202 and a Retry-After header. Nothing is charged.
{
"version": "1.0.0",
"status_code": 40202,
"status_message": "Rate limit exceeded.",
"time": "0.0009 sec.",
"cost": 0,
"tasks_count": 0,
"tasks_error": 0,
"tasks": []
}Best practices
- Send tasks in batches of up to 100 per request instead of one request per product.
- Use webhooks instead of polling task_get in a tight loop; if you poll, call tasks_ready once a minute.
- For products you need regularly, use monitoring — it does not count against your request limits.
- On 429, honour Retry-After; on 5xx, retry with exponential backoff and jitter.
- Need a higher request rate? Write to [email protected] with your expected volume. For more tasks per minute, spread large batches over several minutes or use monitoring.