Secrets

An integration usually needs a credential: an API key for the service it calls, a token, a password. Secrets are where those live, so nobody has to type one into an integration’s headers or URL where the whole team can read it.

Open Settings > Secrets. You need the Tenant Admin role.

Creating a secret

1. Click Create Secret.
2. Secret Key is the name your integrations will use, such as mailchimp_api_key. Lowercase letters, numbers and underscores only, and it cannot be changed later.
3. Secret Value is the credential itself. Paste it in.
4. Description is optional and worth writing. It is the only thing that tells a colleague what this credential is for.
5. Allowed destinations is optional. Leave it empty and the secret works anywhere the integration or webhook using it points. Fill it in to pin the secret to particular hosts, one hostname per line, such as api.example.com.

Pinning a secret to its destinations

A credential usually belongs to one service, and you usually know its hostname: a Mailchimp key goes to api.mailchimp.com and nowhere else. Recording that here means WorkWing refuses to send the secret anywhere but those hosts, so nobody can read the credential back by repointing an integration or a webhook at a server they control.

It is optional because it is a second line of defence rather than the only one: saving an integration or a webhook endpoint that carries a secret already needs the Tenant Admin role. Pin the secrets you can, and the ones you can’t stay usable in the meantime. The list shows Any host when a secret is not pinned.

Whether or not you pin it, a request carrying a secret will not follow a redirect to a different host. If the service you call legitimately redirects across hosts, list both.

Enter bare hostnames, with no https://, no path and no wildcard. A hostname matches exactly: acme.com allows acme.com and not api.acme.com, so list every host you actually call.

One case where pinning is required rather than optional: an integration whose URL builds its own hostname out of a template, such as https://{{input.region}}.api.example.com. There the destination is chosen when the integration runs, by whoever runs it, so every secret it uses has to name its hosts before WorkWing will save it.

Using a secret in an integration

Reference it by key in an integration’s URL, headers or body:

{{secrets.mailchimp_api_key}}

The value is substituted when the request is made. Only a Tenant Admin can save an integration that references a secret. See Custom integrations.

The value is not shown again

Values are stored encrypted. Once you save one, WorkWing does not show it to you again, and there is nothing anywhere that hands it back. The list shows the key, its allowed destinations, the description, a version number and when it was created.

If you lose the original credential, get a new one from the service and rotate the secret.

Rotating a value

Open the secret’s actions menu, choose Rotate Value and paste the new one. The old value stops working straight away, and every integration using the secret picks up the new one on its next run. The version number goes up so you can see a rotation happened.

Editing a secret

Edit Description opens the description and the allowed destinations together. Both can be changed at any time. The key is fixed, and the value only changes through a rotation.

Deleting a secret

Deleting is permanent, and any integration referencing the secret starts failing. WorkWing asks you to type the secret’s key to confirm rather than accepting one click, so check which integrations use it first.

Secrets in execution history

A secret’s value is replaced with [REDACTED] everywhere an integration’s run is recorded, including the response headers it captured. The history stays useful without becoming somewhere credentials leak from.

What’s next

• Custom integrations: how an integration uses a secret