Limite

Limita generală

Fiecare cerere trece printr-o limită comună, numărată pe fereastră fixă de un minut: ceasul pornește la prima cerere, iar după 60 de secunde numărătoarea o ia de la zero. Scrierile și citirile au numărători separate:

Un om lucrează normal sub 30 de scrieri pe minut, deci pragul pe sesiune este de 10 ori mai mare. Pe IP pragul este mai mare fiindcă un birou întreg poate ieși pe aceeași adresă; IP-ul prinde și scripturile fără cookie. O cerere cu o cheie API (Authorization: Bearer ilk_…) se numără pe cheie, cu aceleași praguri ca o sesiune, și pe IP. O cerere fără cookie de sesiune și fără cheie API se numără doar pe IP. OPTIONS nu se numără. Rutele care au limita lor (intrare în cont, OAuth, MCP) o păstrează și pe a lor, peste cea generală.

Antetele de limită

Fiecare răspuns la o scriere spune cât mai ai, după propunerea IETF RateLimit headers (draft 11):

RateLimit-Policy: "sesiune";q=300;w=60, "ip";q=1200;w=60
RateLimit: "sesiune";r=297;t=42, "ip";r=1188;t=42

• RateLimit-Policy: regulile, fixe; q = câte cereri, w = fereastra în secunde.
• RateLimit: starea acum, pe fiecare regulă; r = câte cereri mai ai, t = în câte secunde se golește fereastra.

Partea "sesiune" apare doar când cererea are cookie de sesiune. Citirile nu poartă aceste antete.

Răspunsul la depășire

HTTP/1.1 429 Too Many Requests
Retry-After: 42
Content-Type: application/json

{"eroare": "prea multe cereri"}

La o scriere, Retry-After este numărul de secunde până se golește fereastra epuizată (cea mai lungă, dacă sunt două). La citiri și la limitele proprii ale rutelor, care nu au valoarea lor, Retry-After este 60. Orice 429 al platformei are Retry-After.

Limitele rutelor speciale

Grupurile de mai jos au și ele limita lor, peste cea generală. În afară de cazurile spuse la fiecare grup, depășirea dă 429 cu un corp {"eroare": "..."} și Retry-After: 60. Cu Accept: application/problem+json, prea_multe_incercari, prea_multe_cereri și prea-multe primesc același cod stabil, prea_multe_cereri; limita_utilizator, limita_firma și limita_furnizor își păstrează numele (vezi Erori).

Intrarea în cont

Se numără încercările greșite, nu toate cererile. Fereastra este fixă, de 15 minute.

Blocarea pe cont ține de IP: opt parole greșite de pe altă adresă nu blochează contul pentru cei care intră de la restaurant. Pentru că refuzul pe cont arată la fel ca o parolă greșită, nu afli din răspuns dacă un cont există.

Codurile pe email și schimbarea parolei

Toate rutele de aici numără pe IP, cu fereastră fixă de 15 minute. Pe lângă ele, codul în sine are limitele lui, păstrate în baza de date.

Limitele codului primit pe email:

• Un cod e valabil 10 minute. După expirare, verificarea dă 410 cod_expirat.
• Un cod acceptă cel mult 5 încercări greșite. După ele, verificarea dă 429 prea_multe_incercari, chiar dacă trimiți codul corect. Ceri un cod nou.
• Un cont primește cel mult 5 coduri pe oră. Peste ele, trimite răspunde tot 204, dar codul nu se mai creează.
• Un cod nou le anulează pe cele vechi, de același tip, ale contului.

cod-email/trimite și resetare/cere răspund în cel puțin 400 de milisecunde și la fel, fie că emailul are cont, fie că nu. Un 204 sau un 202 nu înseamnă deci că a plecat un email.

Invitațiile

Se numără separat pe fiecare rută, cu fereastră fixă de un minut. Crearea unei invitații (POST /v1/acces/invitatii, cu sesiune) nu intră aici. Peste prag: 429 prea_multe_cereri.

Asistentul, AI-ul și chatul

Aici se numără pe cont, ca un cont să nu consume bugetul altuia. Ferestrele de un minut sunt glisante.

Pentru asistent, ziua este ziua UTC. Numărătoarea pornește de la zero la miezul nopții UTC, adică la 02:00 sau 03:00, ora României. Rutele care doar citesc starea unei imagini generate, o anulează sau decid asupra ei nu consumă din limită.

Când furnizorul de AI își atinge propria limită, primești 429 limita_furnizor. Asta nu ține de numărătoarea ta: reîncearcă după Retry-After.

Mărimea încărcărilor

Fiecare rută care primește fișiere are o limită pentru tot corpul cererii. Corpul mai mare de atât e oprit înainte de rută și primești 413 {"eroare": "cerere invalida"}. Unele rute verifică după aceea și fișierul în sine.

Diferența dintre corp și fișier lasă loc pentru restul cererii, de exemplu antetele formularului multipart. 1 MiB = 1 048 576 de octeți.

Limitele de mărime și timp

Numărul cererii

Fiecare răspuns are antetul x-request-id. Dacă trimiți tu un x-request-id (8–64 de caractere: litere, cifre, - sau _), platforma îl păstrează; altfel pune unul nou. Când raportezi o problemă cu limitele sau o eroare, trimite acest număr: cererea se găsește după el în jurnalul serverului.