429 För många förfrågningar: vad det innebär och hur man hanterar det

Ett API returnerar 429 Too Many Requests när din app har skickat fler begäranden än vad API:et tillåter under en viss tidsperiod. Själva förfrågan är okej. Du skickade det för ofta, så API:et avvisade den. Om du väntar och skickar det igen lyckas det vanligtvis. Svaret innehåller ofta en Retry-After rubrik som anger hur länge du ska vänta. Mer information finns i RFC 6585, avsnitt 4.

Varje API implementerar begränsningar för anropsfrekvens på olika sätt. Statuskoden, headers och felsvarskroppen varierar, så kod som hanterar ett API på rätt sätt kan hantera nästa API felaktigt.

API Status Så här ser du hur länge du måste vänta Se upp för
GitHub 403 eller 429 retry-after i annat fall x-ratelimit-reset (UTC-epoksekunder) när x-ratelimit-remaining är 0, annars minst 1 minut En 403 kan vara en frekvensbegränsning eller en behörighet som saknas. Läs rubrikerna för att skilja dem åt.
OpenAI 429 retry-after Vissa 429-fel, som credit_balance_exhausted, innebär att omförsök inte hjälper. Kontrollera error.code.
Anthropic 429 retry-after En spend-cap 429 saknar retry-after och fortsätter att misslyckas tills åtkomsten återupptas. Ett överbelastat API returnerar 529, inte 429.
Microsoft Graph 429 Retry-After (sekunder) Gränserna skiljer sig åt per tjänst, till exempel SharePoint och Outlook.

Hantera en 429

  1. Bestäm om du över huvud taget vill försöka igen. Om felet säger att din kvot, dina krediter eller din utgiftsgräns är förbrukad hjälper det inte att försöka igen. Informera användaren och varna dig själv.
  2. Vänta så länge som API:et begär. Om svaret har Retry-After, vänta så länge. Det är antingen ett antal sekunder eller ett HTTP-datum. Om API:et använder rate limit-headerar i stället, till exempel GitHubs x-ratelimit-reset, vänta till återställningstiden.
  3. Annars, backa. Utan en indikation från API:et försöker du igen med exponentiell backoff och slumpmässig jitter och stoppar efter några försök.
  4. Berätta för användaren vad som händer. "Upptagen, försöker igen om 5 sekunder" slår en spinnare som aldrig slutar.
  5. Sakta ner före nästa 429. Om API:et skickar hastighetsbegränsningshuvuden använder du det återstående antalet för att anpassa takten för dina begäranden.
async function fetchWithRetry(url, options, attempts = 3) {
  for (let attempt = 1; ; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === attempts) {
      return response;
    }
    const retryAfter = response.headers.get('retry-after');
    const waitMs = retryAfter
      ? (isNaN(retryAfter) ? new Date(retryAfter) - Date.now() : retryAfter * 1000)
      : 2 ** attempt * 1000 + Math.random() * 1000;
    await new Promise(resolve => setTimeout(resolve, Math.max(waitMs, 0)));
  }
}

Många SDK:er försöker automatiskt igen efter 429-svar. Till exempel försöker OpenAI Python SDK igen 2 gånger som standard och .NET standardhanteraren för återhämtning försöker 3 gånger och respekterar Retry-After. När SDK:t har förbrukat alla återförsök får koden felet, så den behöver fortfarande en plan.

Så här testar du att din app hanterar 429

Du ser sällan en 429 medan du utvecklar. API:et är snabbt, du är den enda användaren och dina testdata är små. Så hur du testar 429-hanteringen avgör om du hittar buggarna innan användarna gör det.

Approach Det här hittar du Vad du saknar
Vänta tills produktionen är klar Faktiska fel Allt, tills en användare träffar den
Mocka API:et i dina tester eller låt kodningsagenten skriva mocken Om grenen för omförsök körs API:ets verkliga statuskoder, rubriker och felsvar samt SDK:ns återförsöksprincip. Din app behöver också en testflagga för att nå mocken.
Anropa det verkliga API:et tills det stryper dina anrop Faktiskt beteende Du kan inte utlösa en 429 på begäran, och du förbrukar din faktiska kvot
Avlyssna appens verkliga trafik och returnera 429 på begäran Verkliga URL:er, din riktiga SDK och återförsöksprincip och API:ets eget 429-format Ingenting i din app ändras, så den testar inte din kod separat. Spara enhetstesterna till det.

Prova det i din app

Dev Proxy fångar upp appens begäranden till de API:er som du väljer och returnerar 429:er, med API:ets egna rubriker och felformat, medan appen fortsätter att anropa de verkliga URL:erna. Den visar också när din app gör ett nytt försök innan Retry-After tiden är slut.

Ladda ned förinställningen för API:et som appen anropar och starta Dev Proxy med den:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"
API Preset
GitHub github-rate-limiting
OpenAI openai-throttling
Anthropic anthropic-throttling
Microsoft Graph (OneDrive och SharePoint: /drive, /shares, /sites) microsoft-graph-rate-limiting

Kör sedan appen som vanligt och se vad den gör. Information om hur du installerar Dev Proxy finns i Set up Dev Proxy.

Nästa steg

Testa så att min applikation hanterar strypning korrekt

Se även

  • Uppdaterades senast