Managing credentials

When your workflows, HTTP request actions, or code scripts need to call an external system, they need credentials to authenticate. Atomicwork gives you two places to manage these — one for outbound calls (Atomicwork calling other systems) and one for inbound access (other systems calling Atomicwork's API). Both are called Credential store in the sidebar, so it's worth understanding which is which before you set anything up.

Preferred approach: connect from the integrations page

Whenever the app you need is available on the integrations page (Settings > App store), connect it there first. Atomicwork handles the OAuth exchange and token refresh automatically, and the secret never leaves the platform. This is the simplest path — no credential management on your end.

If you've connected an app this way, you can call its API directly from a code script using Call API, with no credential references at all. See Use Call API actions in workflows for how that works.

Use the credential store only when the app isn't available on the integrations page, or you need to call an endpoint that the built-in integration doesn't cover.

The credential store

The credential store holds shared credentials that your workflows, HTTP request actions, and code scripts reference by ID. To manage it, go to Settings > Organization > Security > Credential store.

[VISUAL: Screenshot of the credential store at Settings > Organization > Security > Credential store, showing the "Add a credential" button]

Click Add a credential and choose one of three authentication types:

Once saved, reference the credential from any HTTP request action using its ID. The secret itself is resolved server-side and injected into the outbound call — it never has to live in your workflow body or code.

Credential handling

• Never inline secrets. Don't put a token directly in a workflow body, a code script, or source control. Always use a credential reference.

• Reads are masked. Read endpoints return ******** in place of the stored value. Only organization-level credential administrators can reveal the actual secret.

• Rotation means replacing the credential value in the store. Since integrations only hold the credential reference, you're updating the credential itself — not hunting down every place the secret was used.

• Allowed hosts. We'd recommend setting allowed hosts on each credential (e.g. github.com or *.salesforce.com) to restrict where it can be sent. This way, a credential saved for one system can't accidentally be used against another.

Public API tokens

Public API tokens are tied to your individual account and authenticate calls made into the Atomicwork API — not calls going out to other systems. To manage yours, go to Settings > My account > Credential store.

[VISUAL: Screenshot of Settings > My account > Credential store, showing the "Create token" button and existing tokens]

The page title reads Public API token. You'll see tokens you've created, each with a name, a masked token value, and a creation date.

[!NOTE] Public API tokens and the credential store are different things, despite both sidebar items being called Credential store. Use the organization-level credential store (under Security) for outbound integrations — it's shared across the organization and doesn't depend on any one person's access. A public API token is tied to one person and stops working when their account is deactivated or their permissions change, so it should not back a production integration.

Quick comparison

Learn more

• HTTP request actions — using saved credentials in workflow HTTP requests

• Use Call API actions in workflows — calling connected apps from code (no credentials needed)

• Calling external systems — the complete guide to outbound integrations

• API reference: Introduction — authenticating with the Atomicwork API using public API tokens