---
title: "What are scenario secrets?"
description: "Encrypted storage for Send Request and custom action secrets: purpose, supported types, and Action Jail integration."
---

# What are scenario secrets?

**Scenario secrets** are encrypted, instance-level storage for secrets used by **scenario actions** (mainly Send Request HTTP calls and custom actions from the Action Library).

## Why separate storage

Previously, tokens and passwords often lived in node parameters, bot constants, or custom action code. That made it hard to:

- **Rotate** keys across many nodes.
- **Export/import** scenarios without leaking secrets in JSON.
- **Control access** to plain-text values.

Scenarios now store a **reference** to a secret record. Decryption happens **only on the server** when the action runs.

## What you can store

Record types in v1:

| Type | Typical use |
|------|-------------|
| Bearer | Authorization: Bearer … |
| Basic | Login + password |
| API key | Key in header, query, or body |
| Custom headers | Arbitrary secret headers |
| OAuth2 client credentials | token_url, client_id, client_secret |
| SMTP | host, port, user, password |
| Telegram bot | bot token |
| HMAC secret | request signing |
| Generic secret | root only; custom fields for custom actions |

## What is not here (v1)

- **Channel** tokens (Telegram channel bot, Viber, WhatsApp, etc.).
- **Mailgun** and **AI provider** keys.
- **Email** OAuth accounts (Gmail/Outlook).
- Placeholders like `{{secrets.NAME}}` in scenario text.
- Automatic migration of all legacy constants into scenario secrets storage.

Those credentials stay in their own product areas.

## How this connects to Send Request

1. An administrator creates a record under **Settings → Scenario secrets**.
2. An integrator inserts secret references into the URL, headers, or body in Scenario Builder (**Insert secret reference**, **Insert auth header**).
3. The scenario stores a reference marker, not the secret value.
4. Older nodes with a **Credential** dropdown or Basic/Bearer **still work** without changes.

## Custom actions (Action Jail)

- **Credential**-type parameters in the action JSON config let integrators pick a record from the list in Scenario Builder without typing the secret.
- In custom action code, authors call **server-side helpers** to obtain headers or individual field values at runtime — values are not shown in the editor. Ready code snippets appear under **Scenario secrets → Scan legacy secrets** (**Custom actions** tab).
- If action parameters contain HTTP fields with reference markers (like Send Request), authors must **resolve** them explicitly before sending — only the **Send Request** node does this automatically.
- See [Use scenario secrets in a custom Action Jail action](/en/actionjail/how-to/use-saved-credential-in-custom-action.md).

## Security and permissions

- The UI list shows **metadata** and a masked preview (`Bearer ***`) only.
- **Allowed consumers** limit which actions may use a record (e.g. Send Request only).
- **Deletion** is blocked while a record is referenced in a scenario (including inline references).
- The capability is **enabled by the instance administrator**; without that, the tab and insert buttons do not appear.

## Scenario import

On import, the system tries to match the **slug** on the target instance. Inline markers and legacy slug references match by slug. If no record exists, you get a **warning** and must create it manually. There is no cross-instance mapping wizard.

## Related

- [Manage scenario secrets](/en/settings/how-to/manage-action-credentials.md)
- [Use scenario secrets in Send Request](/en/scenariobuilder/how-to/use-saved-credential-in-send-request.md)
- [Use scenario secrets in a custom Action Jail action](/en/actionjail/how-to/use-saved-credential-in-custom-action.md)