Authentifizierung
Bearer-Schlüssel, sichere Ablage, Einschränkungen und Rotation.
Die öffentliche API (/api/v1) akzeptiert ausschließlich Bearer-Schlüssel im Authorization-Header. Cookies und Zugangsdaten in Query-Parametern werden nicht unterstützt.
Authorization: Bearer sk-spicy-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGeplanter Schlüsselwechsel
Sperren Sie einen vermutlich kompromittierten Schlüssel sofort, ohne auf die Umstellung zu warten. Bei einer geplanten Rotation ohne Sicherheitsvorfall erstellen Sie zuerst einen neuen Schlüssel, stellen die Anwendung um, prüfen den Betrieb und sperren danach den alten Schlüssel.
Schlüssel mitsenden
Senden Sie bei jedem Aufruf unter /api/v1 den Header Authorization: Bearer sk-spicy-…. Öffentliche API, Benutzerkonsole und Betriebsoberfläche sind getrennte Authentifizierungsbereiche; ihre Zugangsdaten sind nicht austauschbar. Die kompatiblen APIs unter /v1 und /v1beta akzeptieren zusätzlich x-api-key (Anthropic SDK) und x-goog-api-key (Google GenAI SDK). Schlüssel in der URL-Query werden nirgends akzeptiert.
Sicher speichern und begrenzen
Bewahren Sie Schlüssel nur im eigenen Backend oder in einem Secret Manager auf. Separate Schlüssel pro Umgebung lassen sich ohne Ausfall der übrigen Umgebungen sperren und rotieren.
- Begrenzen Sie die täglichen, monatlichen und kumulierten Ausgaben.
- Bei festen ausgehenden IP-Adressen können Sie eine Liste zulässiger IP-Adressen festlegen.
- Erlauben Sie nur die benötigten Modelle und setzen Sie passende Ausgabenlimits.
Bei einem Leck
Sperren Sie den alten Schlüssel sofort, schalten Sie auf einen neuen um und prüfen Sie taskId, request_id, Quell-IP, Modelle und Kosten in der Konsole. Ungültige Schlüssel liefern HTTP 401.
Die vollständigen Felddefinitionen stehen im OpenAPI-3.1-Vertrag.