How to Get an Access Token Using the Salesforce Client Credentials Flow: Salesforce to Postman

If you’ve ever tried to hit a Salesforce API from an external system and didn’t want a human logging in every time, you’ve probably landed on the OAuth 2.0 Salesforce Client Credentials Flow. It’s the go-to choice for server-to-server integrations, scheduled jobs, and anything that needs to talk to Salesforce without a person sitting there approving a login.

This guide walks through the whole thing end to end from setting up the External Client App in Salesforce, enabling the flow, and pulling an access token in Postman so you can start calling the API. So lets get token using Salesforce Client Credentials Flow in Postman.

Salesforce Client Credentials Flow : Overview

Most OAuth flows in Salesforce assume there’s a human in the loop somewhere someone logging in, approving a consent screen, or refreshing a token. The Client Credentials Flow skips all of that. The app authenticates using just its own Consumer Key and Consumer Secret, and Salesforce hands back an access token immediately, no login screen involved.

Every API call made with that token runs under the permissions of a specific Salesforce user, called the Run As user, which you configure once when you set this up. That’s the part worth sitting with for a second: this flow doesn’t create some special “app-only” access level . It borrows a real user’s permission set, so whatever that user can see and do, the token can see and do.

Use this flow when:

• You’re building a backend integration or a scheduled job with no user present
• Your org enforces SSO, which breaks flows that expect an interactive login
• You want one predictable service identity for an integration, instead of tying it to someone’s personal login

Step 1: Create an External Client App in Salesforce

Salesforce renamed what used to be “Connected Apps” to External Client Apps, so if you’ve done this before under the old name, the steps are largely the same with a new menu location.

1. From Setup, type External Client Apps into the Quick Find box and select External Client App Manager.
2. Click New External Client App.
3. Give it a name and a contact email.
4. Check Enable OAuth.
5. For Callback URL, enter any placeholder value like “https://login.salesforce.com/services/oauth2/callback ” this flow never actually redirects anywhere, but Salesforce still requires the field to be filled in.
6. Under OAuth Scopes, add at minimum:
   • Manage user data via APIs (api)
   • Perform requests at any time (refresh_token, offline_access) — optional, but useful if you’ll also use other flows later
     

7. Scroll down and check Enable Client Credentials Flow. Salesforce will show a security warning read it, then accept it. It’s warning you that anyone who gets hold of the Consumer Key and Secret can generate a token, so treat those two values like a password.
8. Click Create.

Step 2: Set the “Run As” User

Creating the app isn’t enough on its own , you still have to tell Salesforce which user’s permissions the flow should borrow.

1. Open the app you just created in External Client App Manager.
2. Go to the Policies tab and click Edit.
3. Under OAuth Policies → OAuth Flows and External Client App Enhancements, confirm Enable Client Credentials Flow is checked.
4. Set Run As (Username) to the integration user you want this app to act as. For a production integration, this should almost always be a dedicated integration user not your own personal login with only the permissions the integration actually needs. Give that user the API Only permission if you don’t want them able to log in through the normal UI at all.
5. Save.
   

A quick word on why the dedicated user matters: whatever this user can’t see, the token can’t see either, no matter what scopes you granted the app. If a report later shows the integration touching data it shouldn’t, the first thing to check is this user’s profile and permission sets, not the app’s OAuth scopes.

Step 3: Get Your Consumer Key and Secret

1. Still inside your app, go to the Settings tab.
2. Expand OAuth Settings.
3. Click Consumer Key and Secret. Salesforce will ask you to verify your identity usually a code sent to your email.
4. Copy both the Consumer Key and Consumer Secret somewhere safe. You’ll need both in Postman next.
   

While you’re here, also grab your My Domain URL from Setup (search “My Domain”) — it’ll look something like https://yourdomain.my.salesforce.com. You’ll need this for the token endpoint.

Step 4: Request the Access Token in Postman

Now the part that actually gets you a usable token.

1. Open Postman and create a new request. The method and URL here don’t matter much yet — you’re about to configure this at the request’s Body tab.
2. Go to the Body tab .
3. Click Configure New Token (or scroll to the token configuration section).
4. Fill in the fields like this:
   

HTTP Method: POST

Endpoint URL: https://<your-salesforce-domain>[.my.salesforce.com/services/oauth2/token](https://.my.salesforce.com/services/oauth2/token)

Body Format: Select x-www-form-urlencoded

Key-Value Parameters:

grant_type: client_credentials

client_id: [Your Consumer Key]


client_secret: [Your Consumer Secret]

HTTP Method: POST

Endpoint URL: https://<your-salesforce-domain>[.my.salesforce.com/services/oauth2/token](https://.my.salesforce.com/services/oauth2/token)

Body Format: Select x-www-form-urlencoded

Key-Value Parameters:

grant_type: client_credentials

client_id: [Your Consumer Key]


client_secret: [Your Consumer Secret]

5. Click “Send” . If everything’s configured correctly, Postman will show you a token response with an access_token value.
   

Step 5: Make Your First Authenticated API Call

With the token attached, you can now hit any Salesforce REST API endpoint. For example, to check your org’s API limits:

GET https://yourdomain.my.salesforce.com/services/data/v62.0/limits
Authorization: Bearer <your_access_token>

GET https://yourdomain.my.salesforce.com/services/data/v62.0/limits
Authorization: Bearer <your_access_token>

If it works, you’ll get back a JSON response listing your org’s API usage limits — which is a nice, low-risk way to confirm the whole setup is wired correctly before you point it at anything real.

If you’d rather do this outside Postman’s UI, the raw request looks like this:

curl https://yourdomain.my.salesforce.com/services/oauth2/token \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CONSUMER_KEY" \
  -d "client_secret=YOUR_CONSUMER_SECRET"

curl https://yourdomain.my.salesforce.com/services/oauth2/token \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CONSUMER_KEY" \
  -d "client_secret=YOUR_CONSUMER_SECRET"

Common Errors and What They Actually Mean

• “unsupported_grant_type” — Client Credentials Flow isn’t enabled on the app, or you’re hitting the wrong endpoint. Double check Step 1 and Step 2.
• “invalid_client_id” — the Consumer Key is wrong, or you copied it from the wrong app.
• “no client credentials user enabled” — the Run As user field in Policies wasn’t set, or wasn’t saved. Go back to Step 2.
• A 401 on your actual API call, even though the token request worked — the Run As user doesn’t have permission to the object or field you’re calling. Remember, the token has exactly this user’s access, nothing more.
• IP restriction errors — if your org enforces login IP ranges, either add Postman’s IP range to the allowlist or relax IP restrictions specifically for this app in its OAuth policies (only do this if you understand the security trade-off).

A Security Note Worth Actually Reading

Because this flow has no user consent step, anyone who gets the Consumer Key and Secret can request a token with the full permissions of your Run As user. Salesforce’s own warning when you enable this flow is not just boilerplate treat these two values with the same care as a database password:

• Never commit them to a public repo or paste them into a shared Slack channel
• Rotate the Consumer Secret periodically, and immediately if you suspect it’s been exposed
• Keep the Run As user’s permissions as narrow as the integration actually needs resist the temptation to just point it at a full admin account to “make things easier”

Need User-Based Authentication Instead?

The Client Credentials Flow is designed strictly for headless, machine-to-machine integrations (like scheduled background jobs or server-to-server syncs). If your application requires actual users to log in through a browser with their own Salesforce credentials, you need to use the Authorization Code Flow.

• User Login vs. Automated Systems: Client Credentials runs under a single dedicated integration identity. Use the Authorization Code Flow when actions must be tied to individual users logging in.
• Granular Security & Access Control: Authorization Code Flow automatically enforces the specific user’s Salesforce profile, role hierarchy, and field-level permissions.
• Support for MFA & SSO: Handles browser redirects, Salesforce login screens, multi-factor authentication (MFA), and single sign-on seamlessly.

👉 Read the full step-by-step guide: How to Get an Access Token Using the Salesforce OAuth Authorization Code Flow