Credentials
Store the API keys your actions use — encrypted at rest, referenced by name, never shown to the model, and rotated by saving over the name.
An action that calls your systems usually needs a secret. Credentials are where those live, so a token is never pasted into an action's URL or into a system prompt.
Adding one
Settings → Credentials, owners and admins only.
| Field | Limit | Notes |
|---|---|---|
| Name | ≤ 120 chars | How actions refer to it — make it descriptive |
| Provider | ≤ 120 chars | Optional label, e.g. stripe, zendesk |
| Secret | ≤ 8,000 chars | The token itself |
The secret is encrypted at rest. Listing credentials returns metadata only — name, provider, when it was added — never the value. There is no way to read a secret back out of the dashboard.
How an action uses one
Reference the credential by name in the action's configuration. At call time evoriqa decrypts it and sends it as Authorization: Bearer <secret> on the outbound request.
The model never sees it. It is added to the HTTP request after the agent has decided to call the action, so a secret cannot be extracted by asking the chatbot nicely.
Rotating and removing
Saving a credential under an existing name replaces the secret — that is a rotation, and any action referencing that name picks the new value up on its next call. Deleting a credential leaves any action referencing it without authentication, so its calls will start failing: update the action, or add a replacement under the same name.
Give each credential the narrowest scope the action needs. An action that only reads orders should not hold a key that can issue refunds — the guardrails around actions limit which host is called, not what the token is permitted to do there.
Where to go next
Last updated