Credentials
API keys, tokens and passwords that Decisimo needs in order to call something on your behalf live in one place: Admin Center → Credentials.
Storing them here rather than typing them into each screen means a credential exists once, under a name. The data source, LLM model or OCR service that needs it holds only a reference — secret:openai_main — so the value itself never sits in a configuration, an export or a release.
Adding a credential
Click + Credential and fill in:
| Field | |
|---|---|
| Name | How the rest of the platform refers to it, for example openai_main. Lowercase letters, digits, underscore and dash; it has to start with a letter and stays under 64 characters. It cannot be changed later. |
| Kind | What sort of credential it is (see below). The kind decides how the value is checked. |
| Description | Optional note for whoever reads this list in six months. |
| Value | The credential itself. |
Saving does not ask for your password. Adding a credential does not change anything that already runs.
Kinds
| Kind | Expects |
|---|---|
| LLM API key | A provider key, at least 8 characters |
| OCR API key | An OCR service key, at least 8 characters |
| Google service account | The full service-account JSON, including type, project_id, private_key and client_email |
| HTTP bearer | A bearer token, at least 8 characters |
| HTTP basic | user:password — the colon is required |
| HMAC secret | A signing secret, at least 8 characters |
| Generic | Anything else; no shape is enforced |
Picking the wrong kind is not fatal, but the checks that catch a truncated paste come from it, so it is worth getting right.
The value is write-only
Once saved, the value can never be read back — not through the screen, not through the API, not by an administrator. The list shows the name, the kind, the version and when it was last changed, and nothing else.
If you lose the original, you do not recover it from Decisimo; you get a new one from the provider and rotate.
Using a credential
Anywhere a credential is needed — a data source header or parameter, an LLM model's API key, an OCR service — the field offers the credentials you have already stored. Pick one and the configuration keeps the reference.
You can also just type the credential into that field. It is taken into the vault as you save, given a generated name, and the field is left holding the reference. The value never reaches the stored configuration either way; typing it is a shortcut for creating it, not a way around the vault.
Only credentials that are enabled and not deleted are offered.
Rotating
Rotate replaces the value and adds a version. Everything that references the credential by name picks up the new version on its next run; nothing needs repointing.
Rotating asks for your password. That is deliberate — rotation changes what live configurations resolve to, so it takes more than a hijacked browser tab.
A run that pins an exact version (secret:openai_main@3) keeps getting that version. References without a version — which is nearly all of them — always mean "current".
You can rotate a credential up to ten times an hour.
Disabling and deleting
Disable leaves the credential in place but makes it unusable: anything resolving it fails until you enable it again. It is the reversible way to take a credential out of service, and the right first move when you suspect one has leaked.
Delete first checks what still points at the credential. If anything does, the delete is refused and you are told which data sources, models or services are holding it. Point those at another credential first — the same way a rule set cannot be deleted while a decision flow still uses it.
Once it goes ahead, from that moment:
- every reference to the credential fails immediately — there is no quiet period,
- the name stays reserved, so a new credential cannot silently take its place,
- the encrypted value is kept for 30 days and then destroyed.
The 30 days are not a grace period during which things keep working. They exist so that an accidental delete can be investigated, and so the audit trail still has something to point at.
Sync health
Credentials are pushed to the execution nodes that run your decision flows. The detail page shows whether that push has landed:
- Pending — queued, not yet sent.
- Failed — the push did not land. A reason is shown: the node could not be reached (it will be retried automatically), the node refused the update, or the update could not be prepared.
- Last pushed — when the last successful push happened.
Retry sync queues the current version again. A credential that has not synced yet still works everywhere the platform reads it directly; it is the execution nodes that are behind.
Who can do what
Access is granted per role, under Admin Center → User roles, on the Credentials right:
- Read — see the list and pick credentials in configuration screens. Without it, credential pickers appear empty rather than showing an error, which reads exactly like "nothing has been stored yet".
- Write — add, rotate, disable and enable.
- Execute — delete.
Reading a credential's value is not a permission anyone has. Resolution happens on the server while a decision runs and does not consult these rights.