Benutzung
Rate-Limits und Guthaben
Pro Key gelten Anfragen- und Token-Grenzen je Minute; der Verbrauch wird aus dem Prepaid-Guthaben der Organisation gedeckt.
Grenzen pro Key
Die Werte hängen am Tarif der Organisation und sind Betriebsgrenzen gegen Lastspitzen, kein Funktionsmerkmal.
| Tarif | Anfragen / Minute | Tokens / Minute |
|---|---|---|
| Standard | 60 | 200.000 |
| Pro | 60 | 200.000 |
| Max | 300 | 1.000.000 |
Beide Flächen zählen dieselben Anfragen je Minute pro Key. Wer mehr braucht, verteilt Last auf mehrere Keys oder spricht uns an.
Antwort-Header
Die App-API sendet auf jeder authentifizierten Antwort drei Header; bei 429 zusätzlich retry-after.
| Header | Bedeutung |
|---|---|
x-ratelimit-limit | Erlaubte Anfragen im aktuellen Fenster. |
x-ratelimit-remaining | Verbleibende Anfragen im Fenster (fehlt, wenn der Zähler gerade nicht verfügbar ist). |
x-ratelimit-reset | Sekunden bis zum Beginn des nächsten Fensters (Obergrenze). |
retry-after | Nur bei 429: Sekunden, bevor ein erneuter Versuch sinnvoll ist. |
HTTP/1.1 429 Too Many Requests
retry-after: 60
x-ratelimit-limit: 60
x-ratelimit-remaining: 0
x-ratelimit-reset: 60
{ "error": { "code": "rate_limited", "message": "Too many requests. Retry after the indicated delay.", "request_id": "…" } }Guthaben
Der Verbrauch über die API wird in Euro vom Prepaid-Guthaben der Organisation abgebucht — getrennt vom Abo und unabhängig vom Nutzungskontingent der Plätze. Es gibt keinen monatlichen Reset.
Wie die Entwickler-API abgerechnet wird, steht auf der Preisseite.
Empfehlungen
- Bei 429 und 503 exponentiell zurücktreten; retry-after respektieren.
- Für lange Antworten streamen — die Verbindung bleibt schlank und Timeouts werden seltener.
- Embeddings gebündelt anfragen statt einzeln.
- Ein Key pro Anwendung: Limits und Verbrauch bleiben zurechenbar.