Snelheidslimieten
Een snelheidslimiet op deze API is een plafond per bucket binnen een vast venster: de limiter telt een verzoek in het API-proces, laat de eerste verzoeken door en weigert het volgende met 429 rate_limit_exceeded. De onderstaande tabel wordt weergegeven op basis van hetzelfde object dat de limiter leest, dus elk getal hier is een toegepaste limiet en geen samenvatting van een intentie.
| Bucket | Limiet | Venster | Geteld |
|---|---|---|---|
| key_chat inferentieaanroepen gedaan met één API-sleutel |
600 | 1 min | per API-sleutel |
| org_chat inferentieaanroepen binnen een hele organisatie |
1800 | 1 min | per organisatie |
| platform platform-API-aanroepen: organisatie, sleutels, gebruik, traces, beleid |
300 | 1 min | per API-sleutel |
| public_chat anonieme playground-aanroepen |
20 | 1 h | per IP-adres |
| public_page verzoeken voor openbare pagina's |
300 | 1 h | per IP-adres — not enforced |
| public_card_request model card-verzoeken die via het openbare formulier worden verzonden |
5 | 1 h | per IP-adres |
| auth pogingen tot inloggen, registreren, wachtwoordherstel en wachtwoordreset |
20 | 15 min | per IP-adres |
A row marked as not enforced is defined in the limiter table but no request path checks it on this deployment. It is listed so the absence is visible rather than silent: a number in the documentation is not an applied limit.
Gelijktijdigheid
Maximaal 8 verzoeken mogen tegelijkertijd in behandeling zijn op één API-sleutel, geteld per sleutel en niet per organisatie. Een verzoek daarboven wordt onmiddellijk geweigerd met dezelfde 429 — er is geen wachtrij om in te wachten.
Hoe een weigering eruitziet
Een geweigerd verzoek is HTTP 429 met type rate_limit_error en code rate_limit_exceeded. Deze deployment zet geen retry-after en geen x-ratelimit-*-responsheaders, dus de body is de enige klok: waar de limiter het einde van het venster kent, eindigt het bericht daarmee in ISO 8601 (Retry after 2026-10-06T12:00:00.000Z); het bericht per organisatie noemt helemaal geen tijd. Wacht tot dat moment of schakel over op exponentiële backoff — eerder opnieuw proberen kan niet slagen, omdat de teller alleen opschuift wanneer het venster rolt. Behandel een 429 als opnieuw te proberen; elke andere fout in deze documentatie vereist dat het verzoek verandert voordat het kan slagen.
Waar de teller zich bevindt
Vensters worden geteld in het API-proces en elke 15 seconden en bij afsluiten teruggeschreven naar de tabel rate_limits, dus een herstart zet het venster voort in plaats van een nieuw budget uit te delen. Het plafond dat daaruit volgt wordt vermeld in plaats van ontdekt: de teller is per API-node, dus twee nodes verdubbelen elke effectieve limiet. REDIS_URL is gereserveerd voor de gedeelde versie en niets leest het nog — draai één API-node, of accepteer limieten per node.
Veelgestelde vragen
What is a rate limit on this API?
A ceiling per bucket inside a fixed window. The limiter counts a request in the API process, lets the first 600 through inside a 1 min window on one API key, and refuses the next one with 429 rate_limit_exceeded. The window starts at the first request after the previous window ended, and every number in the table above is read from the object the limiter itself reads.
Which limit counts my chat calls — the key or the organization?
Both, and both have to pass. key_chat counts 600 inference calls per API key in 1 min, org_chat counts 1800 across the whole organization in the same window. A call that reaches either ceiling is refused, and the message says which one: the per-key message carries the window reset instant, the per-organization message does not.
Do I have to read the message to find out when to retry?
For a limit counted per key or per IP address, yes. This deployment sets no Retry-After header, so the reset instant inside the message text — an ISO 8601 timestamp taken from the limiter's own window end — is the only clock the response carries. For the per-organization limit the message names no time at all, so back off exponentially there. A retry before the window rolls cannot succeed: the counter only moves when the window does.
Is the counter shared across API nodes, or per process?
Per API process. Windows live in memory and are written back to the rate_limits table every 15 seconds and on shutdown, then restored on boot, so a restart continues a window instead of handing out a fresh budget. Two API nodes therefore double every effective limit. REDIS_URL is reserved for the shared version and nothing reads it yet, so run one API node or accept per-node limits.
Are all of these limits actually applied?
No. public_page is defined in the limiter table but no request path checks it on this deployment, and the table above marks it as not enforced for that reason. Every other row is named at a limiter call site, which is what applied means on this page.
How many requests may be in flight at once on one key?
8 at most. The count is kept per API key, raised when a call enters the chat handler and lowered when it finishes, and a request above the cap is refused at once with the same 429 rate_limit_exceeded — there is no queue behind it.