> ## Documentation Index
> Fetch the complete documentation index at: https://developers.jobhandy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate Limits und Backoff

> Lesen Sie Quota-Header, berücksichtigen Sie Retry-After und steuern Sie Parallelität, ohne sich auf ein undokumentiertes festes Limit zu verlassen.

Rate Limiting wird auf den API-Key angewendet. Der öffentliche Vertrag definiert kein einheitliches numerisches Kontingent, das Clients fest codieren sollten. Lesen Sie die Response-Header, um die wirksame Richtlinie und aktuelle Verfügbarkeit zu ermitteln.

## Response-Header

| Header             | Bedeutung                                                                           |
| ------------------ | ----------------------------------------------------------------------------------- |
| `RateLimit-Policy` | Wirksame Request-Kontingentrichtlinie als HTTP Structured Field                     |
| `RateLimit`        | Aktuelle Kontingentverfügbarkeit und wirksames Zeitfenster                          |
| `Retry-After`      | Wartezeit in Sekunden, wenn die Zulassung aufgrund der Request-Rate abgelehnt wurde |
| `X-Request-ID`     | Korrelations-ID der Response                                                        |

Eine Rate-Limit-Response verwendet HTTP `429` und `RATE_LIMIT_EXCEEDED`.

## Behandlungsablauf

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart TD
    A[Response empfangen] --> B{Status 429?}
    B -- Nein --> C[Normale Verarbeitung fortsetzen]
    B -- Ja --> D[Retry-After lesen]
    D --> E[Neue Versuche für diesen Key pausieren]
    E --> F[Jitter und Retry-Budget anwenden]
    F --> G[Mit neuer X-Request-ID wiederholen]
```

## Empfehlungen für Clients

* Codieren Sie kein Kontingent fest, das nicht durch die wirksamen Response-Header definiert wird.
* Begrenzen Sie parallele Anfragen pro API-Key.
* Teilen Sie den Rate-Limit-Zustand zwischen Workern, die denselben Key verwenden.
* Verwenden Sie zufälligen Jitter, um synchronisierte Retries zu vermeiden.
* Stoppen Sie Retries, sobald das Budget der Operation ausgeschöpft ist.
* Trennen Sie Retry-Behandlung von Queues für fachliche Validierungsfehler.
* Rotieren Sie Keys nicht, um Rate Limits zu umgehen.

## Beispiel

```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
HTTP/1.1 429 Too Many Requests
RateLimit-Policy: ...
RateLimit: ...
Retry-After: 60
X-Request-ID: 018f3d9a-7dfb-7a23-b4b4-9f7e4b19d4b4
```

Warten Sie mindestens 60 Sekunden, bevor Sie einen weiteren rate-limitierten Versuch mit dem betroffenen Key starten, und wenden Sie anschließend das Retry-Budget des Clients an.

<Note>
  Der OpenAPI-Vertrag beschreibt die Semantik der Header, aber keine kundenspezifischen oder dynamisch wirksamen Zahlenwerte. Behandeln Sie die Live-Response-Header als maßgeblich.
</Note>