Rate Limits
sunor enforces rate limits to ensure fair usage and platform stability. Limits are applied per API key.Limits
| Endpoint Type | Limit | Description |
|---|---|---|
| Task creation | 60 requests / minute | POST /api/v1/task |
| Task queries | 120 requests / minute | GET /api/v1/task/{taskId} |
| Account endpoints | 120 requests / minute | GET /api/v1/account/* |
Rate limit headers
Every API response includes rate limit information in the headers:| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum number of requests allowed in the current window |
X-RateLimit-Remaining | Number of requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp (seconds) when the rate limit window resets |
Example response headers
When you hit the limit
If you exceed the rate limit, the API returns a429 Too Many Requests response with a Retry-After header indicating how many seconds to wait.
Response headers on 429
| Header | Description |
|---|---|
Retry-After | Number of seconds to wait before retrying |
Best practices
Respect Retry-After
When you receive a 429 response, wait for the duration specified in the
Retry-After header before making another request.Use exponential backoff
For automated systems, implement exponential backoff when receiving rate limit errors to avoid hammering the API.
Batch wisely
Instead of submitting many tasks simultaneously, spread submissions over time to stay within limits.
Monitor remaining quota
Check
X-RateLimit-Remaining in response headers to proactively slow down before hitting the limit.