What to do when a request is rate limited, and which headers you can and cannot rely on.
Requests are rate limited. RegEngine does not publish limit values.
API keys are rate limited, and so are requests per workspace and per endpoint scope. If you need to plan around a higher volume of requests, contact us to discuss your requirements.
Some successful responses carry rate-limit metadata. It is not guaranteed on every response, and it is not sent reliably on a 429 Too Many Requests, so treat these headers as optional and never build retry logic on them.
| Header | Description |
|---|---|
| X-RateLimit-Limit | The maximum requests allowed in the current window for this scope. |
| X-RateLimit-Remaining | Requests remaining in the current window. |
| X-RateLimit-Reset | Unix timestamp for the next rate-limit window boundary. |
| X-RateLimit-Tenant | The workspace ID the limit was applied to. |
| X-RateLimit-Scope | The bucket the request was counted against (for example webhooks.ingest). |
If you exceed a rate limit, the API returns 429 Too Many Requests. Stop sending for 60 seconds, then retry. Do not wait for a Retry-After header: a 429 does not reliably carry one. The body is the usual error object (see Error Codes); some 429s instead return {"error": "rate_limit_exceeded", "detail": "..."}.
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
{
"error": {
"type": "http_429",
"message": "Rate limit exceeded"
}
}