Limits by plan
| Plan | Requests per minute |
|---|---|
| Free | 100 |
| Starter | 1,000 |
| Pro | 5,000 |
| Team | 5,000 |
| Business | 100,000 |
| Enterprise | 100,000 |
Response headers
Every authenticated API response includes rate limit headers:| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed in the window |
X-RateLimit-Remaining | Requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp (seconds) when the window resets |
When rate limited
When you exceed the limit, the API returns429 Too Many Requests with a Retry-After header:
Retry strategy
Best practices
Monitor remaining quota
Monitor remaining quota
Check the
X-RateLimit-Remaining header in responses and throttle proactively when it gets low, rather than waiting for 429 errors.Use webhooks for events
Use webhooks for events
Instead of polling for status changes, use platform webhooks to receive real-time event notifications.
Cache read-heavy data
Cache read-heavy data
For data that doesn’t change frequently (service catalog, monitor configurations), cache responses locally and refresh periodically.
Batch operations with Config as Code
Batch operations with Config as Code
Instead of creating monitors one at a time via API calls, define them in
devhelm.yml and deploy in a single operation.