Anropsgränser

#Gränsen

Varje nyckel får göra 120 anrop i minuten. REST-API:t och MCP-servern räknas i samma fönster, så en AI-assistent och en synkronisering som delar en nyckel delar också dess gräns; ge dem en nyckel var.

En synkronisering som läser 500 deltagare per sida läser 60 000 deltagare inom gränsen, så en välbyggd integration når den sällan. En loop som frågar efter samma sak om och om igen når den inom en minut, och det är just det gränsen är till för.

#Var du står

Varje svar, avvisningar inräknade, anger gränsen i två former: IETF:s RateLimit-huvuden och de X-RateLimit-*-huvuden som de flesta klientbibliotek läser.

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) är antalet anrop som återstår i det här fönstret och t antalet sekunder tills ett nytt fönster börjar.

#När du går över

Anropet avvisas med 429 Too Many Requests, ett Retry-After-huvud i sekunder och ett problem med "code": "rateLimited". Inget har gjorts: vänta och skicka det sedan igen. Ett avvisat anrop räknas i nycklarnas aktivitet, så att du kan se när det hände.

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." }

#Håll dig gott och väl inom gränsen

• Be om stora sidor: limit=500 går bra.
• Synkronisera med updatedSince i stället för att läsa allt varje gång (Sidindelning och synkronisering).
• Använd webhooks i stället för att fråga efter det som just har hänt.
• Skicka If-None-Match med den ETag du har: en 304 går snabbt, även om den fortfarande räknas.
• Pausa när RateLimits r blir lågt, i stället för att vänta på att bli avvisad.

Fönstret räknas per server, så en hektisk dag kan en nyckel då och då få lite mer än gränsen. Bygg inte på det: lita på huvudena.