Håndter hastighetsgrenser og serverfeil

Håndter et 429-svar

En forespørsel som begrenses, returnerer 429 Too Many Requests med detail.status satt til rate_limit_exceeded. Les svarheaderne før du prøver på nytt:

• Retry-After angir minimum ventetid i sekunder for en avvist forespørsel.
• X-RateLimit-Limit viser grensen for bøtten.
• X-RateLimit-Remaining viser hvor mange forespørsler som gjenstår.
• X-RateLimit-Reset viser når bøtten tilbakestilles.

Vent så lenge Retry-After angir, og prøv deretter på nytt med eksponentiell backoff og jitter. Reduser parallelle forespørsler og legg arbeid i kø i stedet for å sende en stor mengde idet vinduet tilbakestilles.

Håndter serverfeil

Ved et 500-svar inneholder den offentlige kroppen en generell feil og request_id; interne unntaksdetaljer returneres ikke. Et 503-svar kan bety at en nødvendig tjeneste midlertidig ikke er tilgjengelig.

Prøv skrivebeskyttede forespørsler på nytt med en begrenset backoff. Før du prøver en opprettings-, oppdaterings-, betalings- eller annen tilstandsendrende forespørsel på nytt, må du finne ut om det første forsøket ble fullført. Et tidsavbrudd eller 5xx-svar beviser ikke at en endring mislyktes, og en umiddelbar gjentakelse kan føre til dobbelt arbeid.

Ta vare på feilsøkingsdata

Registrer tidspunkt, metode, bane, status, svarkropp og X-Request-Id. Logg aldri x-api-key-verdien. Stopp automatiske nye forsøk etter et lite, begrenset antall forsøk, og vis feilen for gjennomgang.