Authorization: Bearer <token> header.
Tumban accepts two token kinds:
- API keys (
sk_…) — long-lived secrets you create in the dashboard or via Create API key. Use these for server-to-server integration. - Session tokens — short-lived credentials issued to a signed-in dashboard user. Used by the Tumban dashboard. You generally do not handle these directly.
Header format
sk_ is treated as an API key; anything else is
treated as a session token.
What API keys can do
API keys are scoped to your organization and can call every endpoint in this reference except the five management endpoints below. These require a dashboard session because they mutate authentication or organization-wide configuration.
API keys hitting any of these endpoints get
403 — credential
management is intentionally locked out of sk_… auth so a leaked key
cannot mint, list, or revoke other keys. See
Errors → common detail strings for
the exact detail text to match on.
Each request looks up the key by SHA-256 hash, scopes the request to the
key’s organization, and updates the key’s last_used_at timestamp.
Revoked keys return 401 Invalid or revoked API key.
Rotating an API key
Tumban does not expire API keys automatically. To rotate:- Create a new key and deploy it to your servers.
- Once traffic has cut over (watch
last_used_aton the old key via List API keys), revoke the old key.
Storage
Tumban only stores the SHA-256 hash of an API key. The rawsk_… value is
returned exactly once at creation time. If you lose it, revoke the key and
create a new one.
Organization identifier
Every authenticated request resolves to exactly oneorg_id. Tumban
treats it as an opaque, case-sensitive string — do not regex-match
it against a hex or numeric alphabet. The leading org_ prefix is the
only guaranteed part of the shape. Examples (org_2abc...) in this
reference are illustrative; the body is alphanumeric and may include
mixed case.
Errors
See Errors for the full error envelope.

