Rate Limiting
The ZopNight API enforces per-organization rate limits at the gateway. Reference for limits, the 429 response, and best-practice backoff strategy.
The ZopNight API enforces rate limits per organization to ensure fair usage and service stability.
How It Works
Rate limiting is applied at the gateway level, tracked per organization using Redis. Limits are based on the number of requests per minute.
| Parameter | Value |
|---|---|
| Default limit | 100 requests per minute per organization |
| Scope | Per organization (all users in an org share the limit) |
| Window | Fixed 1-minute window (resets on each clock minute boundary) |
| Per-endpoint variations | None — every org-scoped endpoint shares the same bucket |
| Response headers | No X-RateLimit-* headers are returned. Rely on the 429 response. |
| Auth endpoints | Not rate limited (separate from org-scoped limits) |
Rate Limit Response
When the rate limit is exceeded, the API returns a 429 status:
json
HTTP 429 Too Many Requests
{
"error": "rate limit exceeded"
}Best Practices
- Implement exponential backoff — when you receive a 429 response, wait before retrying. Double the wait time with each retry (1s, 2s, 4s, etc.).
- Cache responses — avoid redundant API calls by caching resource lists, schedules, and other data that changes infrequently.
- Use batch endpoints — fetch multiple resources with
/resources/by-idsinstead of individual GET requests. - Avoid polling — use reasonable intervals when polling for action status or refresh completion.