Workspace secrets
Keep tokens and secret URLs out of decisions — workspace secrets referenced as {{secrets.NAME}}, who can manage them, how they are stored and masked, and when changes apply.
API tokens, passwords and secret URLs — a Slack or n8n webhook URL — don't belong in a decision: the schema is versioned, shown in the editor and stored with every deploy. Keep them in workspace secrets and reference them by name.
Add a secret
In Settings → Destinations → Secrets, enter a name and a value and click Add secret (or Replace for an existing name).
- Names are UPPER_SNAKE_CASE: a capital letter, then capital letters, digits and
_, up to 64 characters —CRM_TOKEN,SLACK_WEBHOOK. - Values are 1 to 4,096 characters and write-only: once saved, the app shows the name, the last 4 characters (to Admins) and when it changed — never the value.
- A workspace keeps up to 50 secrets.
Use it
Write {{secrets.NAME}} where a destination needs it:
| Where | Example |
|---|---|
| A header value | Authorization: Bearer {{secrets.CRM_TOKEN}} |
| A whole URL | {{secrets.SLACK_WEBHOOK}} as the URL of an API request or a webhook |
An http body | {"api_key": {{secrets.MAILER_KEY}}} |
A secret can be the start of a URL — the whole URL — or part of a header or a body. Secrets can't be used in fixed replies, LLM prompts and inputs, or agent instructions: that text is returned to the caller or sent to a model.
Who can do what
| Viewer | Member | Admin | Owner | |
|---|---|---|---|---|
| See secret names (to write templates) | — | ✓ | ✓ | ✓ |
| See the last 4 characters | — | — | ✓ | ✓ |
| Add, replace and delete secrets | — | — | ✓ | ✓ |
| Reveal and rotate the signing secret | — | — | ✓ | ✓ |
How they are protected
- Encrypted at rest with AES-256-GCM. Values never leave the API except inside the request they are rendered into.
- Never in the decision schema, the API response, the execution log or the Playground: previews show
••••in their place, and the delivery log keeps only a masked preview of each request — method, URL, headers and the body's size. - The full request, with secrets, is stored encrypted while a delivery may still need it — see Delivery and retries.
When changes apply
Secrets are read when the decision runs: Dcision renders the request with the current values and stores it, encrypted, for its attempts.
- A new or changed value applies to the next runs. Deliveries already queued — and their retries — keep the request they were rendered with.
- A destination that references a secret that doesn't exist fails its delivery at once, with "Set the secret CRM_TOKEN in Settings → Destinations, then resend." — nothing is sent. Because the request was rendered without the secret, add it and run the decision again: resending that delivery fails the same way. An agent in
syncmode returns"status": "failed"with the same advice. - Deleting a secret makes the destinations that use it fail until it is set again.
The signing secret
Separate from these secrets, every workspace has one signing secret (whsec_…) that signs all its deliveries. Admins and the Owner reveal and rotate it in Settings → Destinations → Signing secret — see Verify the signature and Rotate the signing secret.
Functions
Let your own code act on a result — the response names the function and its params, and the TypeScript and Python SDKs call the handler you registered, in order and once per call.
Delivery and retries
How Dcision delivers webhooks, API requests, workflows and agent hand-offs — at least once, six attempts over about seven hours, Retry-After, timeouts, statuses, resends and retention.