Secrets
Secrets are named, encrypted values that a workflow can use without ever having the sensitive value typed into the workflow itself. An API key, a shared password, a signing token: you store it once as a secret, give it a name, and then refer to that name wherever a step needs it. The actual value stays protected.
Why use a secret
If you paste an API key straight into a step’s settings, that key becomes part
of the workflow’s design, visible to anyone who can open the workflow and stored
in its history. A secret avoids that. The value is encrypted when you save it,
and a step only ever sees the real value for the brief moment it needs to do its
job. It never shows up in run history, and it appears masked as ******* when
you step through a run.
Storing a secret
Create a secret with a short name and its value. A few rules apply to the name:
- Lowercase letters, numbers, and underscores only.
- Must start with a letter.
- Up to 64 characters.
Good names read like crm_api_key, webhook_secret, or sftp_password.
For safety, the value is write-only. After you save a secret, its value is never shown again, not even to you. If a key changes, update the secret with the new value (this is called rotating it). To use a different name, delete the secret and create a new one.
Using a secret in a workflow
Reference a secret by its group and name, the same way you reference any other value:
In practice you pick it from the builder’s value picker rather than typing it. You can also combine a secret with other text in an expression, which is how you build things like an authorization header:
The secret stays protected even inside a combined value like this one.
Fields that require a secret
Some steps ask for a credential directly, such as a Slack token, an SFTP password or key, or a form service’s API key. For these fields the builder shows a secret picker instead of a plain text box, and the value must come from a secret. This keeps credentials out of workflow definitions by default.
Changing or deleting a secret does not disturb runs already in progress; they keep the value they started with. New runs pick up the change within a moment. If you delete a secret that a workflow still refers to, later runs will fail when they try to use the missing value.