Skip to main content

Integrations

Credentials​

Credentials allow you to securely save and reuse any credentials or tokens used to authenticate outgoing webhooks or Send Request steps with third-party services within your Action Flows.

Adding credentials​

  1. Go to: Configuration > Integrations > Credentials. Alternatively, open the command palette and type Credentials.
  2. Select New credential.
  3. Fill out the details for the type of credential (see below) and its parameters.
  4. Select Save.

Client credentials (OAuth)​

Client credentials perform an OAuth client_credentials call to your chosen Identity URL and pre-populates a Authorization: Bearer ... header containing the returned access token.

caching

The resolved OAuth credentials are cached within the Atomic platform for 45 seconds after initially being retrieved. This is to avoid overloading the OAuth endpoint with requests. Any token expiration settings should be longer than 45 seconds.

Any query parameters included in your Identity URL are merged with the OAuth parameters, allowing you to include any extra parameters required by your identity provider.

The OAuth client credentials flow supports the following request schemes:

POST with body parameters​

OAuth parameters are URL encoded with a content type of application/x-www-form-urlencoded and sent in the request body to your Identity URL as a POST request.

curl --location --request POST https://login.microsoftonline.com/common/oauth2/v2.0/token \
    --header 'Content-Type: application/x-www-form-urlencoded' \
    --data-urlencode 'grant_type=client_credentials' \
    --data-urlencode 'client_secret=MY_CLIENT-SECRET' \
    --data-urlencode 'client_id=MY_CLIENT_ID' \
    --data-urlencode 'scope=MY_SCOPE'

POST with query parameters​

OAuth parameters are sent as query parameters to your Identity URL as a POST request with no request body. This method is used by certain implementations of the OAuth client credential flow, such as Zoho CRM.

curl --request POST 'http://my.auth.com/oauth2/v2.0/token?grant_type=client_credentials&client_secret=MY_CLIENT-SECRET&client_id=MY_CLIENT_ID&scope=MY_SCOPE'

GET with URL query parameters​

OAuth parameters are sent as query parameters to your Identity URL as a GET request.

curl --request GET 'http://my.auth.com/oauth2/v2.0/token?grant_type=client_credentials&client_secret=MY_CLIENT-SECRET&client_id=MY_CLIENT_ID&scope=MY_SCOPE'

AWS Signed Request​

Authenticate a request with AWS IAM allowing Atomic to interact with AWS services. We recommend creating a bot user in AWS with IAM policy access granted with least-privileged access for use with this credential type.

See the AWS documentation for information on signed requests in AWS.

  • Access key ID: the ID of the access key associated with the AWS IAM user.
  • Secret access key: the secret access key associated with the AWS IAM user.
  • Sign query: optionally sign the request query instead of adding an Authorization header.
  • Session token: optionally provide the session token to use IAM STS temporary credentials.
  • Service: the AWS service which you are interacting with, this is added to the signed credentials header exactly as it is entered.
    • i.e. AWS4-HMAC-SHA256 Credential=ACCESS_KEY_ID/20241022/us-east-1/**THE_SERVICE**/aws4_request...
  • Region: the AWS region which you are interacting with, this is added to the signed credentials header exactly as it is entered.
    • i.e. AWS4-HMAC-SHA256 Credential=ACCESS_KEY_ID/20241022/**THE_REGION**/THE_SERVICE/aws4_request...

Basic auth​

Adds "Authorization: Basic ..." header containing the provided credentials, base64 encoded.

security

This option is less secure as it allows the username and password in your request to be decoded. Consider using the alternative options where possible.

Key-pair​

Adds "Authorization: Bearer ..." header containing the produced JWT.

Produces a JWT based on a public and private key. The private key is entered into Atomic and the public key is used in another system to verify the produced JWT.

caching

The resolved JWT is cached in the Atomic system for 90% of the expiry period of the produced JWT. A new token is then created when this cache expires, the next time this credential is used.

Custom headers​

Applies the configured headers to requests where this credential is used. This is useful for systems that use a static API key that you don't want to manually add to the headers of each Action Flow or webhook where requests are made to that system.

Google service account​

Adds "Authorization: Bearer ..." header containing the produced JWT.

Allows authentication with Google APIs via a service account. Follow the steps below to create a service account in Google Cloud, download its credentials, and enable the relevant API.

Create a Google service account​

  1. Open the Google Cloud Console and select the project you want to use (or create a new one).

  2. In the left-hand navigation, go to IAM & Admin > Service Accounts.

  3. Click Create service account, enter a name and optional description, then click Create and continue, then Done.

Create and download a JSON key​

  1. In the list of service accounts, click on the service account you just created, then open the Keys tab.

  2. Click Add key > Create new key, select JSON as the key type, and click Create. A JSON file will be downloaded to your computer — keep this file secure.

Enable the relevant Google API​

  1. In the Google Cloud Console, go to APIs & Services > Enabled APIs & Services.

  2. Click Enable APIs and Services, search for the API you need (for example, Google Calendar API or Google Sheets API), and enable it for your project if it is not already enabled.

Once you have the JSON key file, open it and use the values it contains to fill in the credential fields in the Atomic Workbench.

Share resources with your service account

For Google Sheets and Google Calendar, access is granted at the resource level rather than via project-wide IAM roles. Remember to share each spreadsheet or calendar directly with the service account's email address (visible in the Google Cloud Console under IAM & Admin > Service Accounts), giving it the appropriate permission (e.g. Editor for Sheets, or the relevant access level for Calendar).

caching

The resolved JWT is cached in the Atomic system for 5 minutes. A new token is then created when this cache expires, the next time this credential is used.

Salesforce Data 360 (beta)​

Adds "Authorization: Bearer ..." header containing a Salesforce Data 360 (formerly Data Cloud) access token.

beta

This credential type is in beta. The setup and field names may change as we refine it.

Salesforce Data 360 uses a two-step authentication. Atomic performs both steps for you: it first requests a Salesforce Core access token, then exchanges that token for a Data 360 access token, which is added to your request. You only need to provide your Connected App details.

Set up a Connected App in Salesforce​

  1. In Salesforce Setup, create a Connected App (or External Client App) with OAuth settings enabled.

  2. Enable the client credentials flow and assign the integration user it should run as.

  3. Add the Data 360 OAuth scopes you need (for example cdp_ingest_api, cdp_query_api, or cdp_profile_api) along with api.

  4. Copy the consumer key and consumer secret for the Connected App.

Fill in the credential in Atomic​

Enter the following fields when adding the credential in the Workbench:

  • Login URL: your Salesforce My Domain base, for example https://your-domain.my.salesforce.com. This is used for both authentication steps.
  • Client ID: the Connected App consumer key.
  • Client secret: the Connected App consumer secret.
  • Dataspace: the Data 360 dataspace to target. Leave as default unless you use a named dataspace.
  • Scope (optional): the OAuth scope to request.
Point your request at the Data 360 host

When you use this credential in a Send Request step or webhook, set the request URL to your tenant's Data 360 host (for example https://<tenant>.c360a.salesforce.com/api/v1/ingest/sources/<source>/<schema>), not your my.salesforce.com domain. Atomic supplies the access token; you supply the Data 360 endpoint. You can find your Data 360 host in Salesforce after authenticating.

caching

The resolved Data 360 access token is cached in the Atomic system for 5 minutes. A new token is then created when this cache expires, the next time this credential is used.

AWS​

Premium feature

AWS S3 integrations are a premium feature. Please contact us to have this feature enabled in your organization.

The AWS tab in the Configuration area of the Workbench is where you will configure the Atomic side of our integration plugin with AWS S3.

Learn about how Atomic and AWS connect, including how to configure the integration in the following articles:

Salesforce​

Premium feature

Salesforce integrations are a premium feature. Please contact us to have this feature enabled in your organization.

The Salesforce tab in the Configuration area of the Workbench is where you will configure the Atomic side of our integration plugin with Salesforce Marketing Cloud.

Learn about how Atomic and Salesforce connect, including how to configure the integration in the following articles:

Marketo​

Premium feature

Marketo integrations are a premium feature. Please contact us to have this feature enabled in your organization.

The Marketo tab in the Configuration area of the Workbench is where you will configure the Atomic side of our Self Service Flow Step integration with Marketo.

Learn about how Atomic and Marketo connect, including how to configure the integration in the following articles:

Last updated on