Keys

Throughline keeps two separate shelves of credentials. They look similar — both live under a production's Settings — but they do opposite jobs, and mixing them up is the mistake this page exists to prevent.

Your provider keys

Your provider keys are the model and API credentials a production supplies for its own AI usage — an image-generation provider, a language model provider, whatever the production has an account with. Bring your own key, and Throughline uses it on the production's behalf for the AI features that need one.

Provider keys are write-only. Once saved, the credential itself is never returned — not to the admin who entered it, not to crew, not over the API. Throughline shows only a label, a last-4 stub, and who set it and when, so you can confirm a key is in place without anyone ever reading the value back out. The full credential exists in exactly one place: encrypted at rest, decrypted only at the moment Throughline uses it on the production's behalf.

Provider keys are never exposed to crew. A department head using a feature that calls out to a provider never sees, needs, or can retrieve the underlying credential — the production's admin manages it once, centrally.

Throughline access keys

Throughline access keys are the keys Throughline itself issues for API access — what you send as Authorization: Bearer tl_... against the REST API. A production's admin mints one from Settings, gives it a label describing what it's for, and picks its scopes (read, write, or both). The full token is shown exactly once, at creation; after that Throughline keeps only a recognizable prefix, the same way a provider key's plaintext is never retained.

Scoping

• One key, one production. An access key is bound to the production it was minted on. There is no key that reaches across productions.
• Scopes, not roles. read and write are independent — a key can hold either or both, and an endpoint that needs write refuses a read-only key outright rather than degrading silently.
• Revocation is immediate. Revoking a key from Settings takes effect on the very next request; there's no propagation delay to account for.

What an access key can't do

An access key authenticates as the production, not as a specific crew member's session. It can read and write within the scopes it holds, but it never gains a person's own permissions, never sees another production, and carries none of the write access a signed-in person has outside the documented write endpoints.

Which one do I need?

• Wiring up a model provider so the production's assistant or generation tools can use it → Your provider keys.
• Building or connecting a tool that reads or writes production data over the API → Throughline access keys.