Source: https://atomicwork.docs.pageloop.ai/product/platform-administration/governance/managing-credentials # 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](/product/enterprise-workflows/actions-and-integrations/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: | Type | When to use | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **API key** | The receiving app issues a key or token. For bearer-style authentication, use this type — set the header name (e.g. `Authorization`) as the key, and the token value (e.g. `Bearer sk-xxx`) as the value. There is no separate bearer type. | | **Username and password** | The receiving app uses basic auth. | | **No authentication** | The endpoint accepts unauthenticated requests. | 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 | | Credential store | Public API tokens | | -------------- | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | **Path** | **Settings > Organization > Security > Credential store** | **Settings > My account > Credential store** | | **Direction** | Outbound — Atomicwork calling external systems | Inbound — external systems calling the Atomicwork API | | **Scope** | Shared across the organization | Tied to one person | | **Use for** | HTTP request actions, webhook integrations, code scripts that call external APIs | Personal API access, testing, scripts that call Atomicwork's API as you | | **Auth types** | API key, username/password, no auth | API key (`X-Api-Key` header) | #### Learn more - [HTTP request actions](/product/enterprise-workflows/actions-and-integrations/http-request-actions) — using saved credentials in workflow HTTP requests - [Use Call API actions in workflows](/product/enterprise-workflows/actions-and-integrations/use-call-api-actions-in-workflows) — calling connected apps from code (no credentials needed) - [Calling external systems](/guides/connecting-your-workflows-to-external-systems) — the complete guide to outbound integrations - [API reference: Introduction](/api-reference) — authenticating with the Atomicwork API using public API tokens