Keys

Owners manage two kinds of credentials under Settings > Keys:

• Model provider keys bill model calls to your account with that provider.
• The end-user JWT secret lets your backend identify signed-in users of your app.

Publishable keys, which select an agent for an installation, are created separately in the agent's Install section.

Add a model provider key

Create a key with Anthropic or OpenAI, then paste it into the corresponding provider section in Teaflask. Anthropic keys start with sk-ant-; OpenAI keys start with sk-.

Teaflask checks the saved key with a minimal provider call. The row shows its state:

State	Meaning
Verifying…	The check is running. Calls continue to use your balance when platform funding is available.
Active	The key pays for that provider's model calls.
Declined	The provider rejected the key. That provider's models stop running until you update or remove the key — a declined key never falls back to your balance.

An active key covers only its own provider. Calls to another provider can still spend the organization's balance. See Billing.

Provider keys are available on all plans. They are optional: you can fund usage through your Teaflask balance instead. After saving, only the key's prefix and last four characters are displayed; the full key cannot be revealed again.

Replace or remove a provider key

Replace key removes the old key immediately and sends the replacement through verification. There is no overlap between the two keys. While the replacement is being checked, calls can use your balance.

Remove key returns that provider's usage to your balance. If the balance cannot fund the work, add funds or restore a valid key for that provider. Removing a declined key is also how you hand its provider's usage back to the balance, since the declined key itself admits no work.

Auto top-up pauses while any provider key is active, even if another provider still draws from your balance. Check your balance when using a mix of provider-funded and Teaflask-funded models.

Identify your app's users

The Identity verification section contains your organization's end-user JWT secret. Your backend uses it to sign short-lived HS256 tokens identifying your app's users. See Identity for token fields, signing examples, and frontend integration.

Owners can reveal the secret again in the Teaflask dashboard. Keep it on your backend; never embed it in your customer-facing frontend or send it to your users. Your frontend receives the signed token, not the signing secret.

A supplied token that is invalid or expired is rejected with HTTP 401. It does not silently turn the user into an anonymous visitor.

Rotate the identity secret

Rotate secret generates a new value. Tokens signed with the old secret stop verifying immediately, with no grace period.

Prepare your backend update before rotating, then:

1. Rotate the secret in Teaflask.
2. Update your backend's secret storage with the new value.
3. Ensure your backend signs new tokens with it and your frontend token callback obtains fresh tokens rather than returning cached old ones.

Identified requests using the old secret will fail during the cutover. The new value does not exist until you rotate, so plan the backend update to follow that step promptly.