Rate Limiting
Rate limits enforced by the Elizon Public API.
The Public API enforces two independent rate limits on every request. Both are evaluated per 60-second window.
Two-layer model
| Layer | Scope | Default | Configurable? |
|---|---|---|---|
| Organization (primary) | All requests from your organization, across every key | 1000 requests/minute | Per-organization, set by Elizon |
| Per-key (secondary) | Requests from one specific API key | Unlimited (no per-key limit) | Optional, set when the key is created |
The organization limit is checked first. If it's exceeded, the request is rejected before the per-key limit is even evaluated. If the organization limit passes and the key has a configured per-key limit, that's checked next. A key with no configured limit only ever counts against the organization limit.
Call GET /organizations/limits to read your organization's and key's current configured limits.
Response headers
Every response — including 429s — carries the organization-level headers. The two key-level headers are only present when the calling key has a configured per-key limit.
| Header | Description | Example |
|---|---|---|
X-RateLimit-Limit | Organization limit, requests/minute | 1000 |
X-RateLimit-Remaining | Requests left in the organization's current window | 842 |
X-RateLimit-Reset | Unix timestamp (seconds) when the current window ends | 1732550460 |
X-RateLimit-Key-Limit | This key's configured limit, requests/minute (omitted if unlimited) | 100 |
X-RateLimit-Key-Remaining | Requests left for this key in the current window (omitted if unlimited) | 37 |
X-RateLimit-Reset is an absolute timestamp, not a countdown — subtract the current time yourself if you need seconds-until-reset.
429 response
Exceeding either limit returns 429 with a Retry-After header (seconds until the window resets) and a matching retry_after field in the body:
429 Too Many Requests
Retry-After: 23
{
"error": "rate_limit_exceeded",
"message": "Organization rate limit exceeded. Retry after 23 seconds.",
"retry_after": 23
}A per-key limit violation returns the same shape with "message": "Per-key rate limit exceeded. Retry after 23 seconds.".
Recommended retry pattern
Read retry_after from the body (or the Retry-After header — they're always equal) and back off at least that long before retrying. Add jitter and exponential backoff on top if you're retrying a batch of requests, so they don't all wake up in the same instant:
curl --retry 5 --retry-all-errors --retry-delay 2 \
-X POST https://api.elizon.com/api/v1/agents/{agentId}/run \
-H "X-API-Key: elz_your_key_here" \
-H "Content-Type: application/json" \
-d '{"message": "Summarise the Q3 report"}'For your own retry loop, prefer reading retry_after from the response body over a fixed delay — it tells you exactly how long is left in the current window instead of guessing.