Kallgrenser

#Grensen

Hver nøkkel kan gjøre 120 kall i minuttet. REST-API-et og MCP-serveren teller i samme tidsvindu, så en KI-assistent og en synkronisering som deler én nøkkel, deler også grensen; gi dem hver sin nøkkel.

En synkronisering som leser 500 deltakere per side, leser 60 000 deltakere innenfor grensen, så en godt laget integrasjon når den sjelden. En løkke som spør om det samme om og om igjen, når den i løpet av et minutt, og det er nettopp det grensen er til for.

#Hvor du står

Hvert svar, avvisninger inkludert, oppgir grensen på to måter: IETFs RateLimit-headere og X-RateLimit-*-headerne som de fleste klientbiblioteker leser.

HTTP/1.1 200 OK
RateLimit-Policy: "default";q=120;w=60
RateLimit: "default";r=117;t=42
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 117
X-RateLimit-Reset: 42

r (remaining) er antall kall som er igjen i dette vinduet, og t antall sekunder til et nytt vindu begynner.

#Når du går over

Kallet avvises med 429 Too Many Requests, en Retry-After-header i sekunder og et problem med "code": "rateLimited". Ingenting ble utført: vent, og send det på nytt. Et avvist kall telles med i nøklenes aktivitet, så du kan se når det skjedde.

HTTP/1.1 429 Too Many Requests
Retry-After: 18
Content-Type: application/problem+json

{ "status": 429, "code": "rateLimited", "detail": "This key made more than 120 calls in a minute. Try again in 18 seconds; the RateLimit header says what is left." }

#Hold deg godt innenfor

• Be om store sider: limit=500 går fint.
• Synkroniser med updatedSince i stedet for å lese alt hver gang (Sideinndeling og synkronisering).
• Bruk webhooks i stedet for polling for det som nettopp har skjedd.
• Send If-None-Match med ETag-en du har: en 304 går raskt, selv om den fortsatt teller.
• Ta en pause når r i RateLimit blir lav, i stedet for å vente på å bli avvist.

Vinduet telles per server, så på en travel dag kan en nøkkel av og til få litt mer enn grensen. Ikke bygg på det: behandle headerne som fasiten.