# Rate-Limits

<Lead>
Alle öffentlichen Endpunkte der Plattform sind rate-limitiert, damit einzelne Integrationen den Dienst nicht für andere verlangsamen. Diese Seite beschreibt das Antwort-Verhalten und die geplanten Kontingente der REST-API.
</Lead>

## Verhalten bei Überschreitung

Überschreitet eine Integration ihr Kontingent, antwortet die API mit:

<ResponseExample status={429} contentType="application/json">
{`Retry-After: 30

{ "error": { "code": "rate_limited", "message": "Too many requests." } }`}
</ResponseExample>

- Der `Retry-After`-Header nennt die Sekunden bis zum nächsten erlaubten Request.
- Wiederhole nicht sofort in einer Schleife: Warte mindestens die genannte Zeit und nutze exponentielles Backoff mit Zufallsanteil (Jitter), wenn mehrere Worker parallel laufen.
- Rate-Limits gelten pro Workspace, nicht global: Andere Integrationen desselben Workspace teilen sich das Kontingent.

## Geplante Kontingente der REST-API

<BetaNotice>
Diese Werte beschreiben den Planungsstand für die öffentliche REST-API und können sich bis zum Public Launch ändern.
</BetaNotice>

| Tarif | Anfragen pro Minute | Anfragen pro Tag |
|---|---|---|
| Standard | 60 | 5.000 |
| Max | 300 | 50.000 |

Der API-Zugang beginnt mit dem Standard-Tarif; im Compact-Tarif ist er nicht enthalten.

## Was heute schon limitiert ist

Auch ohne REST-API wendet die Plattform Rate-Limits auf ihre öffentlichen Flächen an, zum Beispiel auf Buchungsseiten, Formular-Einsendungen und Webhook-Test-Aktionen. Diese Limits schützen vor Missbrauch und sind bewusst großzügig für normale Nutzung dimensioniert. Wenn deine legitime Integration wiederholt limitiert wird, melde dich beim Support mit Workspace und Anwendungsfall.

## Empfehlungen für Integrationen

<Checklist>
  <ChecklistItem>Antworten mit Status 429 nie ignorieren: `Retry-After` respektieren.</ChecklistItem>
  <ChecklistItem>Exponentielles Backoff mit Jitter statt fester Wiederholungs-Intervalle.</ChecklistItem>
  <ChecklistItem>Massen-Abgleiche in Batches außerhalb von Stoßzeiten planen.</ChecklistItem>
  <ChecklistItem>Wo möglich Webhooks statt Polling verwenden: Sie verbrauchen kein Anfrage-Kontingent.</ChecklistItem>
</Checklist>