OAuth 2.0 connections in Boomi: client credentials and authorization code

Your new CRM, e-invoicing platform or marketplace has a REST API, and its documentation says “OAuth 2.0”. Basic authentication would have been one line; OAuth brings client IDs, token URLs, scopes and refresh tokens. This article explains what is going on behind those terms, which flow to use for an unattended integration, and how to configure it on a Boomi HTTP Client connection.

Why not just call the token endpoint yourself?

A common first attempt is to build the flow by hand: one HTTP call to get a token, store it in a property, add it as a header to the next call. It works in the demo and fails in production:

Tokens expire. Access tokens typically live from a few minutes to an hour. A long-running batch, or a process that runs every five minutes, will eventually call the API with an expired token.
Refresh logic is easy to get wrong. Renewing too often hits the provider’s rate limits on the token endpoint; renewing too late produces 401 errors.
Secrets end up in the wrong places. Hand-built flows tend to put client secrets in process properties, maps or scripts, where they get copied and logged.

The pattern: let the connection own the token

The cleaner pattern is to treat authentication as part of the connection, not the process:

Process ──► Connection (holds client ID, secret, token, refresh logic) ──► SaaS API

The process only says “call GET /customers”. The connection obtains a token, attaches it as Authorization: Bearer ..., and renews it when needed. Credentials sit in one component, which can differ per environment.

Pick the grant type

Question	Grant type
The integration acts as itself, nobody signs in	Client credentials
The API only allows access on behalf of a signed-in user	Authorization code
The provider offers certificate-based client auth (JWT)	JWT bearer, if supported by the API and your Boomi release

For a nightly sync of invoices into an e-invoicing platform, client credentials is the natural choice. For a SaaS app whose API only works “as a user” (common with some CRMs and office suites), you use authorization code once, and the integration keeps working with a refresh token.

Before you start: register the client

In the SaaS provider’s admin console, register an application (sometimes called an app, client or integration) and note:

Client ID and client secret
Token URL (for example https://login.example-crm.com/oauth2/token)
Authorization URL (authorization code only)
The scopes you need, for example customers.read invoices.write
For authorization code: the redirect (callback) URL that the provider must allow. Boomi shows the callback URL to register in the connection screen; copy it from there rather than typing it.

Create a dedicated client per environment (test and production), with only the scopes the integration needs.

Step 1: Create the HTTP Client connection

Create a new Connection component and choose the HTTP Client connector.
Set the URL to the API’s base address, for example https://api.example-crm.com/v2.
Set Authentication Type to OAuth 2.0. An OAuth 2.0 tab or section appears with the grant-specific fields.

Exact field labels can change between Boomi releases, but you will find the same building blocks described below.

Step 2a: Client credentials

Set Grant Type to Client Credentials.
Enter the Client ID and Client Secret.
Enter the Access Token URL (the provider’s token endpoint).
Enter the Scope value exactly as the provider documents it. Most providers use space-separated scopes.
If the provider needs extra parameters on the token request (some require an audience or resource value), add them as additional access token parameters.
Save, then test the connection or run a small test process.

With client credentials there is nothing to “sign in” with: the connector requests a token when it needs one, using the client ID and secret.

Step 2b: Authorization code

Set Grant Type to Authorization Code.
Enter Client ID, Client Secret, the Authorization Token URL and the Access Token URL.
Enter the Scope. Many providers require an extra scope such as offline_access before they issue a refresh token; check the provider’s documentation.
Register the Boomi callback URL shown in the connection with the provider.
Use the button to generate the token. A browser window opens, you sign in to the provider with the account the integration should act as, and approve the requested scopes. Boomi stores the resulting access and refresh tokens with the connection.

Sign in with a dedicated integration user (for example integration@company.gr), not your personal account. Otherwise the integration stops working when you leave or your password changes, and every change it makes appears under your name.

Step 3: Use the connection in an operation

Create an HTTP Client operation for each call: method GET, resource path customers, response profile, and so on. Nothing about tokens appears in the operation or the process. A simple test process: Start (No Data) → Connector (HTTP Client, GET customers?updatedSince=2026-10-01) → Stop. Run it in Test Mode and check the response in the shape’s document viewer.

Step 4: Token refresh and expiry

Client credentials: the connector requests a new token when the current one is no longer valid. You do not store a refresh token.
Authorization code: the connector uses the stored refresh token to get new access tokens. If the refresh token itself expires or is revoked (password reset, admin revocation, an inactivity policy at the provider), calls will fail until someone generates the token again.

Find out the provider’s refresh token policy before go-live. Some refresh tokens never expire, some expire after a fixed period, some rotate on every use. Put the re-authorisation steps in your runbook.

Common errors and what they mean

Symptom	Likely cause
`invalid_client`	Wrong client ID or secret, or a secret from another environment
`invalid_grant` on refresh	Refresh token expired or revoked; generate the token again
`invalid_scope`	Scope name misspelled, or not enabled for this client in the provider
`redirect_uri_mismatch`	Boomi callback URL not registered, or registered with a small difference
`401` on API calls, token request works	Token for the wrong audience or resource, or missing scope for this endpoint
`403` on some endpoints only	Scope or API user permissions are too narrow for that operation
Works in test, fails in production	Production values not set in environment extensions, or wrong token URL

When troubleshooting, look at the HTTP status and the error field in the token response. Avoid turning on logging that prints the Authorization header.

Before you go live

Use environment extensions for client ID, client secret and the URLs, so test and production use different clients. We cover this in Managing secrets and certificates across environments in Boomi.
Request the minimum scopes. Read-only where possible.
Record the secret’s expiry. Many providers make client secrets expire (often after one or two years). Put the date in your rotation calendar.
Handle 429 responses. Token and API endpoints have rate limits; combine this with retries as described in error handling and retries in Boomi.
Document re-authorisation for authorization code connections: who signs in, with which account, and how.

Summary

OAuth 2.0 is less work than it looks once the connection owns the token: pick client credentials for unattended system-to-system calls, authorization code when the API requires a user, keep scopes narrow and secrets per environment. For the wider picture of identities, secrets and certificates in integrations, see our guide Securing integrations: a practical guide.