Secrets: API tokens for your tools

Your API needs a token. A secret is where it lives: encrypted at rest, substituted into the call only at the moment the request leaves, never shown back in the panel, never logged, never visible to the model.

In the panel: the tool’s form → Secrets (Tools and events).

Create one

On the tool’s form, under Secrets: a name and the value. Secrets save at once, not with the form. The name is a slug, unique per tool, and only that tool can reference it.

Then write the placeholder wherever the token goes:

Authorization: Bearer {{secret.api_token}}

or in the URL, a query value or the body template — any string value, never a key.

What you can and cannot do with it

• Write-only. The API serializes a secret as { id, name }; the value is write_only. To rotate, write a new value. To read it back, there is no way — not for you, not for us through the panel.
• Encrypted at rest with the platform’s field encryption.
• Substituted once, in a single regex pass, so a value that itself contains {{…}} is never expanded again.
• Raw into headers and bodies, as you would write it; in a URL it is inserted as is too — put a token where your API expects it, usually a header.
• Part of the response-cache key. The tool’s response cache hashes the fully resolved request, headers included, so a secret never becomes a way for two tenants to share a cached answer; the raw request is never stored.

When a reference is wrong

An unknown placeholder — a name no secret of that tool carries — is left standing as the literal text {{secret.name}} and sent. Your API will refuse it, and the Test button shows you the raw response, which is how you find the typo.

The two other secrets

{{user}} is not a stored secret: it is the logged-in visitor’s own token, relayed per request (User identity). The management API key you use from your own scripts is a different credential again (Authentication). All three share the rule: inserted at the boundary, never stored in a transcript, never in a log.