Authentifizierung

Den Schlüssel mitschicken

Sende den Schlüssel bei jeder Anfrage als Bearer-Token:

Authorization: Bearer tb_live_<your_api_key>

Kann dein Client keinen Authorization-Header setzen - manche No-Code- und Webhook-Tools können das nicht -, wird derselbe Schlüssel auch im Header X-API-Key akzeptiert.

X-API-Key: tb_live_<your_api_key>

Wie Schlüssel gespeichert werden

Ein Schlüssel besteht aus 32 Byte aus einer kryptografischen Zufallsquelle hinter dem sichtbaren Präfix tb_live_. Wir speichern nur seinen SHA-256-Hash, nie den Schlüssel selbst - ein Datenleck in unserer Datenbank liefert also keine funktionierenden Zugangsdaten.

Ein schneller Hash ist hier Absicht statt eines langsamen Passwort-Hashes: Ein API-Schlüssel hat 256 Bit Entropie, es gibt also kein Wörterbuch für Angriffe, und die Prüfung läuft bei jeder einzelnen abrechenbaren Anfrage - ein langsamer Hash wäre dort ein selbstgemachter Engpass.

Schlüssel sicher aufbewahren

• Nutze einen eigenen Schlüssel pro Umgebung und pro Rechner - dann legt das Widerrufen eines Schlüssels nie alles auf einmal lahm.
• Bewahre Schlüssel in Umgebungsvariablen oder einem Secret-Manager auf - nie in der Versionskontrolle und nie in Frontend-JavaScript, das jeder Besucher lesen kann.
• Widerrufe sofort, wenn ein Schlüssel geleakt sein könnte. Der Widerruf greift schon beim nächsten Aufruf.
• Prüfe vor dem Widerrufen Zuletzt verwendet im Dashboard, damit du weißt, ob ein Schlüssel noch im Einsatz ist.

Was ein Schlüssel kann - und was nicht

Ein Schlüssel kann Endpunkte aufrufen und Credits verbrauchen. Er kann keine weiteren Schlüssel erstellen oder widerrufen, keine Abrechnung einsehen und nichts am Zahlungsweg ändern - dafür braucht es eine angemeldete Sitzung. Ein geleakter Schlüssel ist also auf sein Guthaben begrenzt und lässt sich jederzeit im Dashboard abschalten.