# Rate-Limits und Nutzung

Wie Anfragen auf Ihren Plan angerechnet werden, wie die Antwort 429 aussieht und welche Größenbeschränkung für eine einzelne Anfrage gilt.

<Warning>
  **Vorausschauend.** Rate-Limiting, Nutzungsobergrenzen und die Antworten
  `402`, `403`, `413` und `429` sind Teil des API-Vertrags, werden aber **noch
  nicht durchgesetzt**. Diese Seite beschreibt ihr Verhalten, damit Sie einen
  Client bauen können, der darauf vorbereitet ist. Hier werden keine
  Zahlenwerte veröffentlicht, weil keine in Kraft sind.
</Warning>

PDF Blocks ist darauf ausgelegt, unter Last kontrolliert nachzugeben und Ihre
Nutzung sichtbar zu halten. Diese Seite behandelt, wie die Nutzung gemessen
wird, wie sich Rate-Limiting äußert und wie Sie Ihre Anfragen dimensionieren.

## Wie die Nutzung gemessen wird

Die Nutzung wird pro Plan gemessen und in Ihrem
[Dashboard](https://dashboard.pdfblocks.com) nachgehalten. Das Dashboard ist
die maßgebliche Quelle dafür, was Sie auf Ihren Plan verbraucht haben: sowohl
die Anzahl der verarbeiteten Dokumente als auch die Anzahl der gestellten
Anfragen. Prüfen Sie es, um Ihren Verbrauch zu überwachen und zu sehen, wie nah
Sie am Kontingent Ihres Plans sind.

Weil die API *stateless* ist, wird jede Anfrage für sich gemessen; es gibt
keine Sitzungen und keine Stapel, die abzugleichen wären. Eine Aktion mit
mehreren Dokumenten wie ein Aufteilen zählt trotzdem als eine einzige Anfrage.

## Rate-Limits und die Antwort 429

Sobald Rate-Limiting durchgesetzt wird, werden Anfragen, die das Kontingent
Ihres Plans überschreiten, mit `429 Too Many Requests` und einem Antworttext
vom Typ [problem+json](/docs/api/errors) beantwortet. Ein `429` ist
vorübergehend: Dieselbe Anfrage gelingt, sobald Sie langsamer werden.

Bauen Sie Ihre Clients von Anfang an so, dass sie damit umgehen:

- **Exponentielles Backoff verwenden.** Warten Sie bei einem `429`, bevor Sie
  es erneut versuchen, und erhöhen Sie die Verzögerung mit jedem weiteren `429`
  (zum Beispiel durch Verdoppeln), statt sofort in einer engen Schleife erneut
  zu senden.
- **`Retry-After` beachten.** Trägt die Antwort einen Header `Retry-After`,
  warten Sie mindestens so lange, bevor Sie es erneut versuchen, statt Ihre
  eigene Verzögerung zu verwenden.
- **Jitter hinzufügen.** Variieren Sie die Wartezeit leicht zufällig, damit
  parallele Worker nicht im Gleichtakt erneut senden.
- **Versuche begrenzen.** Geben Sie nach einer sinnvollen Anzahl von Versuchen
  auf und melden Sie den Fehler, statt endlos zu wiederholen.

Dieselbe Backoff-Strategie gilt für den seltenen Serverfehler `5xx`.

## Größenbeschränkungen für Anfragen

Sehr große Uploads können mit `413 Payload Too Large` abgelehnt werden. Sobald
diese Grenze durchgesetzt wird, gibt eine Anfrage, deren Text die zulässige
Größe überschreitet, einen Antworttext vom Typ
[problem+json](/docs/api/errors) zurück und wird nicht verarbeitet. Anders als
ein `429` gelingt ein `413` auch bei einem erneuten Versuch nicht: Sie müssen
eine kleinere Datei senden.

Strategien für Uploads und Downloads als Stream, für Zeitüberschreitungen und
für die Verarbeitung großer Dokumente finden Sie unter
[Mit großen Dateien arbeiten](/docs/api/working-with-large-files).

## Antworten rund um die Abrechnung

Zwei weitere reservierte Codes betreffen Ihr Konto und nicht die einzelne
Anfrage:

- **`402 Payment Required`**: eine Bedingung bei der Abrechnung oder beim
  Kontingent Ihres Plans. Klären Sie sie im
  [Dashboard](https://dashboard.pdfblocks.com).
- **`403 Forbidden`**: Ihr Schlüssel ist gültig, darf die angeforderte
  Ressource aber nicht verwenden.

Beide stehen im Katalog [Fehler](/docs/api/errors), zusammen mit der
vollständigen Form der Antwort.
