Authentication

Sending your key

Send the key as a bearer token on every request:

Authorization: Bearer tb_live_<your_api_key>

If your client cannot set an Authorization header - some no-code and webhook tools cannot - the same key is accepted in an X-API-Key header instead.

X-API-Key: tb_live_<your_api_key>

How keys are stored

A key is 32 bytes from a cryptographic random source behind a visible tb_live_ prefix. We store only its SHA-256 hash, never the key itself, so a breach of our database does not hand over working credentials.

A fast hash is deliberate here rather than a slow password hash: an API key has 256 bits of entropy, so there is no dictionary to attack, and verification runs on every single billable request where a slow hash would be a self-inflicted bottleneck.

Keeping keys safe

• Use a separate key per environment and per machine, so revoking one never takes down everything at once.
• Keep keys in environment variables or a secret manager - never in source control, and never in frontend JavaScript where any visitor can read them.
• Revoke immediately if a key may have leaked. Revocation takes effect on the very next call.
• Check Last used in the dashboard before revoking, so you know whether a key is still in service.

What a key can and cannot do

A key can call endpoints and spend credits. It cannot create other keys, revoke keys, view your statement or change billing - those need a signed-in session. So a leaked key is contained to its credit balance and can always be shut off from the dashboard.