Limits and quotas
Limits and quotas in Siper: the periodic token quota, requests per minute (RPM), what a 429 response means, and how to retry correctly with Retry-After.
In normal use you will not hit a limit; the limits are deliberately generous. Two mechanisms apply to your account: a periodic token quota and a per-key requests-per-minute limit. The goal is not to restrict usage; it is to keep the service predictable for everyone.
Token quota
All your requests are deducted from a single token quota defined for the period. Unused tokens do not expire at the end of the period; the quota rolls over and accumulates.
When the quota is used up, the service is not cut off. A warning appears in the panel when you reach 80% of the quota and another when the quota is used up; your requests keep being processed. Remaining tokens, usage rate, and the thresholds are shown live on the “Token kotası” (Token quota) card in the panel; see Panel for where the card is.
Requests per minute (RPM)
A requests-per-minute (RPM) limit can optionally be defined for each API key. The default is unlimited; the limit applies only when explicitly set and protects the service during short bursts of load. The value applied to your key is shown in the key list in the panel; if there is no value, the key is unlimited.
The 429 response and Retry-After
A 429 has two separate causes. The code field in the response tells you which.
Your key’s own limit. When you reach the request or token limit set on the key, the response states the limit, the window and when you can retry:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json
{
"type": "request_limited",
"error": {
"code": "key_request_limit",
"message": "Request limit reached for this API key: 20 requests per 1m. The limit resets every 1m; retry after 60 seconds. An organization admin can change this limit in the panel under API Keys."
}
}
code |
Meaning |
|---|---|
key_request_limit |
The key’s request limit is reached |
key_token_limit |
The key’s token limit is reached |
key_rate_limit |
Both limits are reached |
Retry-After is one full limit window; the limit resets within that time at the
latest. An organization admin changes the limit in the panel on the “API anahtarları” (API keys) screen.
Model provider busy. When the provider stays busy despite the gateway’s own retries, a generic message is returned:
{
"error": {
"code": "provider_busy",
"message": "The model provider is temporarily busy. Please retry shortly."
}
}
This response has no Retry-After. Most OpenAI SDKs retry a 429 on their own; if
you are writing your own client, add retries with increasing intervals.
A 429 is not a quota overrun. When your token quota is used up, requests do not stop, and you only see a warning; a 429 is returned only for the momentary rate limit or a busy provider and resolves on its own shortly.
Organization regex limits
Three limits apply to your organization regexes: at most 25 definitions, at most 200 characters each, and a time budget for scanning. The limits are not arbitrary: a single badly shaped expression can keep masking busy for a long time, and the budget cuts that short.
When the budget is exceeded, the two directions behave differently, and the distinction is deliberate:
- A masking organization regex that exceeds the budget causes the request to be rejected
with
422. We prefer returning an error over silently masking less than we should. - An exemption organization regex that exceeds the budget is simply not applied, and the request completes normally. An exemption reduces masking, and a rule that reduces masking should not take effect under uncertainty.
The same limits apply when you send regex lists directly in the request body. The organization regexes you define in the panel are added to the lists in the request and cannot be dropped by the request body; the result can only increase masking. To define them in the panel, see Panel.
Input length
Each piece of text to be masked has a length limit: 20,000 characters. A
request that exceeds it never reaches the model; it comes back as 413, and the
message says what to do (split the text and retry).
The limit is per text, not per request. That distinction matters for batch work:
- The
inputfield of a/v1/embeddingsrequest may be an array. Three separate 15,000-character documents (45,000 in total) go through fine, because each one is below the limit on its own. - One oversized document in the array, however, fails the whole request. For batch indexing, filter or split documents by length before sending; otherwise a single document forces the entire batch to be resent.
For the array format and fields, see the Create an embedding vector reference.
Summary
| Limit | Default | Behavior when exceeded | Where it is shown |
|---|---|---|---|
| Token quota | Periodic, rolls over | Warning; service is not cut off | Token quota card in the panel |
| RPM | Unlimited; configurable per key | 429 + Retry-After |
Key list in the panel |
| Organization regex | At most 25 definitions, 200 characters | Masking 422; exemption not applied |
“Ayarlar > Kuruma özel regexler” (Settings > Organization regexes) |
| Input length | 20,000 characters per text | 413; the request never reaches the model |
Request response |
If you would like to increase your quota or define a custom limit for a key, get in touch with us.