Working with credentials

Store passwords, API keys and other secrets safely in the vault so processes can use them at run time without anyone seeing the secret – with expiry, rotation and access control.

Help CentreCredentials & Connections

Automations often need a secret – a password, an API key, a token. A credential stores that secret safely in the vault, encrypted at rest, so your processes can use it at run time without anyone ever copying the secret into a step. This keeps secrets out of your process definitions and under proper control.

1. Create a credential

  1. Go to Library › Credentials and create a new credential.
  2. Set the application it's for (e.g. "SAP") and a username where relevant.
  3. Choose the type:
    • Username & password
    • API key
    • Bearer token
    • OAuth2 (client credentials)
    • Certificate
  4. Enter the secret and save. From then on the secret is stored encrypted and is not shown back to you.

2. Where the secret is stored

Most credentials are stored Automize-managed – encrypted in the vault. For username & password credentials you can instead use the bot's local keychain, where the secret lives on the bot's own machine and Automize never holds a copy. An AWS Secrets Manager backend is also available where configured.

3. Using a credential in a process

  • Connector steps – choose the credential as the step's connection.
  • Login steps in a bot process – pick the credential from the picker; the bot retrieves the secret at run time.
  • Secret variables – a variable can point at a credential and resolve to its secret only while the process runs.

4. Expiry, rotation and access

  • Expiry – set a date after which the credential stops working, so stale secrets fail safely.
  • Rotation – set how often it should be refreshed; an overdue credential is blocked until rotated, and Automize warns you before secrets expire.
  • Access control – like any item, credentials use permission levels: viewers see only the metadata, operators (and bots running as them) can use the secret at run time, and admins can edit, rotate or revoke it. Every time a secret is fetched it is recorded in an access log.
  • Revoke – an admin can revoke a credential; its secret is wiped and further use is blocked.
  • What happens on failure – at run time a credential that is missing, expired or revoked fails closed: the step can't get the secret and stops rather than carrying on without it. If your plan doesn't permit a particular connector, you'll see the plan message explaining what's needed.

Related articles

See it working on your own data

Everything documented here ships with the platform – try the document tools free, or go live in 7 days.