Kaldgrænser

#Grænsen

Hver nøgle må foretage 120 kald i minuttet. REST API'et og MCP-serveren tæller i det samme vindue, så en AI-assistent og en synkronisering, der deler én nøgle, deler også dens grænse; giv dem hver sin nøgle.

En synkronisering, der læser 500 deltagere pr. side, læser 60.000 deltagere inden for grænsen, så en velbygget integration rammer den sjældent. En løkke, der spørger om det samme igen og igen, rammer den inden for et minut, og det er netop det, grænsen er til for.

#Hvor du står

Hvert svar, afvisninger inklusive, angiver grænsen i to former: IETF's RateLimit-headers og de X-RateLimit-*-headers, som de fleste klientbiblioteker 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) er de kald, der er tilbage i dette vindue, og t antallet af sekunder, til et nyt vindue starter.

#Når du går over

Kaldet afvises med 429 Too Many Requests, en Retry-After-header i sekunder og et problem med "code": "rateLimited". Intet er udført: vent, og send det så igen. Et afvist kald tæller med i nøglernes aktivitet, så du kan se, hvornår det skete.

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 dig et godt stykke under

• Bed om store sider: limit=500 er helt i orden.
• Synkroniser med updatedSince i stedet for at læse alt hver gang (Sider og synkronisering).
• Brug webhooks i stedet for polling for det, der lige er sket.
• Send If-None-Match med den ETag, du har: en 304 er hurtig, men tæller stadig med.
• Hold pause, når r i RateLimit bliver lav, i stedet for at vente på at blive afvist.

Vinduet tælles pr. server, så på en travl dag kan en nøgle af og til få lidt mere end grænsen. Byg ikke på det: betragt headerne som sandheden.