Integration User
An Integration User is a dedicated Salesforce user account that exists only to be the identity an external system authenticates as when it calls the Salesforce API.
Definition
An Integration User is a dedicated Salesforce user account that exists only to be the identity an external system authenticates as when it calls the Salesforce API. No human logs in as this account. It owns the OAuth credentials, the connected app authorization, and the run-as context that the outside system uses to read and write data.
Salesforce ships a purpose-built license for these accounts called the Salesforce Integration user license, released in the Spring '22 (API version 242) release. That license is API-only, which means the account cannot sign in to any user interface. It pairs with the Minimum Access - API Only Integrations profile and the Salesforce API Integration permission set license, so you grant exactly the access each integration needs and nothing more.
How the Integration User license and profile fit together
Why integrations need their own identity
An integration should authenticate as a dedicated account, never as a real employee. When a person owns the credentials, the integration breaks the moment that person is deactivated or rotates their password. Worse, every record the integration creates or edits gets stamped with that employee's name, so the audit trail no longer tells you who actually did the work. A dedicated Integration User fixes all of that. It is a permanent identity that belongs to the integration itself, not to a colleague who might leave. Separation is the real payoff. When external traffic runs as a clearly named account such as MuleSoft Integration or HubSpot Sync, you can filter Login History and field history by that account and see precisely what each connected system touched. That clarity matters during a security review, a data-quality investigation, or an incident. It also lets you revoke one integration without disturbing any human user. Salesforce documents this one-user-per-integration pattern as a best practice, and it is the foundation for everything else on this page.
The Salesforce Integration license (Spring 22 onward)
Before Spring '22, teams burned a full Sales or Service license on accounts that never opened a screen. Salesforce closed that gap with the Salesforce Integration user license, which is API-only by design. A user on this license cannot log in to Lightning Experience, Salesforce Classic, or any other UI. They exist purely to make API calls over REST or SOAP. The license is available in Enterprise, Unlimited, Performance, and Developer editions. Supported orgs receive a limited number of these licenses by default, and you can buy more through your Salesforce account executive. Treat the exact free allocation as something to confirm with your account team rather than a fixed public number, because it varies. The point is that you no longer pay a premium seat price for a robot. Provisioning the license also creates two assignable items in your org: the Minimum Access - API Only Integrations profile and the Salesforce API Integration permission set license. Those two pieces are what you assemble in the next sections to actually grant data access.
Profile, permission set license, and least privilege
The Minimum Access - API Only Integrations profile does almost nothing on its own, and that is intentional. Salesforce recommends you strip every permission off the profile and grant access only through permission sets and permission set groups layered on top. That way the profile stays a clean, predictable baseline, and the actual data access lives in named, reviewable building blocks. The Salesforce API Integration permission set license is the key that unlocks broader permissions for these accounts. It extends the API-only user with many of the same user and object permissions you would normally find on a System Administrator profile. So the license itself is not narrowly scoped to a fixed handful of objects. The scoping is your job, done through permission sets. The standard approach is one custom permission set per integration, named after the system it serves, listing the exact objects, fields, and Apex classes that integration is allowed to use. Assign the permission set license, then the permission set, and the account can do precisely what you intended and nothing else.
Connected apps and the OAuth Client Credentials Flow
An Integration User does not authenticate with a password typed into a login form. It authenticates through a connected app using an OAuth flow built for machines. The flow Salesforce now recommends for server-to-server traffic is the OAuth 2.0 Client Credentials Flow. There is no interactive consent screen and no end user in the loop, which is exactly right for a backend service. You wire it up inside the connected app. In the connected app's Manage view, set the permitted users policy to Admin pre-authorized, then specify a Run-As User for the Client Credentials Flow and point it at your Integration User. From then on, every API call the external system makes runs as that account. Its CRUD rights, sharing, and field-level access are exactly the Integration User's. The older OAuth 2.0 JWT Bearer Flow remains valid and is still common for certificate-based setups. Both are stronger than the username-password flow, which Salesforce has been retiring because a single password rotation silently breaks the integration.
A worked example: connecting a billing system
Say your finance team runs a billing platform that needs to read Accounts and write Invoice custom records into Salesforce every night. Start by creating a user on the Salesforce Integration license with the Minimum Access - API Only Integrations profile. Name it clearly, something like Billing Integration, so it is obvious in logs. Next, build a permission set called Billing Integration Access. Grant Read on Account, Read and Create on the Invoice object, and field-level access to only the fields the sync touches. Assign the Salesforce API Integration permission set license to the user, then assign your new permission set. Now create a connected app, enable the Client Credentials Flow, and set Billing Integration as the Run-As User. Hand the consumer key and secret to the billing platform. When the nightly job runs, it requests a token, Salesforce returns one scoped to Billing Integration, and the writes land under that account. If finance later switches billing vendors, you deactivate one user and one connected app, and no human account or unrelated integration is affected.
Auditing, monitoring, and migrating older setups
Because external traffic now flows through a clearly labeled account, your audit story gets much simpler. Login History records every authentication by the Integration User, and Setup Audit Trail captures configuration changes. If you own Salesforce Shield, Event Monitoring adds detailed API call logs so you can see read and write volume per account. Filtering any of these by the integration account isolates exactly what the outside system did, cleanly separated from real-user activity. Reviewing that on a regular cadence catches surprises before they become incidents. Many existing orgs still run integrations on old standard licenses. Moving them over is straightforward. Provision the Salesforce Integration license, create a fresh API-only user, attach the permission set license and a least-privilege permission set, then re-point the connected app's Run-As User at the new account. You will usually re-issue credentials to the external system as part of the cutover. Test in a sandbox, switch production, then deactivate the old user and reclaim the standard seat for an actual person.
How to set up an Integration User
Set up a dedicated Integration User on the Salesforce Integration license, grant least-privilege access through a permission set, and let an external system authenticate as it through a connected app. Do this in Setup as an admin.
- Create the API-only user
In Setup, go to Users and create a new user. Assign the Salesforce Integration user license and the Minimum Access - API Only Integrations profile. Give it a clear name such as Billing Integration so it stands out in logs. This account cannot sign in to any UI.
- Grant access with a permission set
Build a permission set named for the integration. Add only the objects, fields, and Apex classes that integration needs. Assign the Salesforce API Integration permission set license to the user first, then assign your permission set. Keep the profile itself empty of permissions.
- Create and configure the connected app
Create a connected app for the external system and enable OAuth settings. In the connected app's Manage view, set the permitted users policy to Admin pre-authorized and specify your Integration User as the Run-As User for the Client Credentials Flow.
- Hand over credentials and test
Give the consumer key and secret to the external system. Have it request an access token and make a sample API call. Confirm in Login History that the call ran as your Integration User, then verify it can only touch the data you scoped.
The API-only license assigned to the user. Available in Enterprise, Unlimited, Performance, and Developer editions, with a limited free allocation.
The baseline profile created with the license. Keep it stripped of permissions and grant access through permission sets instead.
The permission set license that unlocks broader object and user permissions for the account. Assign it before assigning custom permission sets.
The connected app setting that names which Integration User the external system's API calls execute as.
- The license is API-only. The user genuinely cannot log in to any UI, so do not try to test it by signing in to a browser session.
- Never leave permissions on the Minimum Access - API Only Integrations profile itself. Put all access in permission sets so it stays auditable.
- Use one Integration User per external system. Sharing a single account across integrations makes auditing and least-privilege scoping impossible.
- Prefer the Client Credentials or JWT Bearer flow over username-password. A password rotation will silently break a username-password integration.
Prefer this walkthrough as its own page? How to Integration User in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Integration User.
Hands-on resources to go deeper on Integration User.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Integration User account in a typical Salesforce architecture for external API access?
Q2. Why use a dedicated Integration User instead of a real person's account for API callouts?
Q3. What is a security best practice when configuring an Integration User account in Salesforce?
Discussion
Loading discussion…