Salesforce integration users: the Integration license, API-only access and least privilege

Most Salesforce orgs have more integration users than anyone can name. An ETL tool, a marketing platform, a data warehouse sync, a support widget, a middleware layer, each with a login someone created years ago and gave System Administrator "to get it working". Those users rarely log in through a browser, so nobody notices them. They are also the accounts with the broadest data access in the org, and their credentials live in a third party's systems.

This post is about the user side of an integration: which license to use, how to make it API-only, how to give it the least access that works, how it pairs with OAuth, and what to monitor. The OAuth app side (connected apps, scopes and token hygiene) is covered in our posts on connected apps and OAuth tokens and connected app hygiene after token theft.

#One integration, one user

The first rule is the simplest and the most often broken: give each integration its own user. When five tools share one login you cannot tell which one made a change, you cannot revoke one without breaking four, and the shared user ends up with the union of everything all five needed.

A dedicated user also gives each integration its own row in Login History, its own audit trail entries and its own permission set assignments you can review.

#The Salesforce Integration user license

Salesforce provides a license built for this job. According to Salesforce Help on integration users, the Salesforce Integration user license makes two things available:

• The Minimum Access - API Only Integrations profile, which restricts the user to API access. Users on this license cannot use the Salesforce user interface. (It replaces the older Salesforce API Only System Integrations profile, which newly provisioned orgs no longer get.)
• The Salesforce API Integration permission set license, which you assign so the user can be granted object and field permissions through permission sets.

The design pushes you toward the right pattern: start from a profile that grants almost nothing, then add access through permission sets scoped to the integration. Check how many of these licenses your org has under Company Information in Setup.

If an integration genuinely needs a different license (some vendor packages require a standard Salesforce license, for example), you can still make the user API-only with the API Only User permission, which blocks UI login.

#Least privilege, concretely

"Least privilege" turns into a short list for an integration user:

1. Objects and fields. Grant read, create or edit only on the objects the integration touches, and only the fields it maps. A warehouse sync that reads Accounts and Opportunities does not need Cases, and does not need edit at all.
2. No org-wide powers. Modify All Data, View All Data, Author Apex, Customize Application and Manage Users turn an integration credential into an admin credential. If a vendor asks for them, ask which API calls need them.
3. Record access. View All and Modify All on an object bypass sharing for that object. Prefer a role, a sharing rule or a public group that grants the records the integration actually processes.
4. Network. Set Login IP Ranges on the profile, or require trusted IPs through the connected app, so a stolen credential does not work from anywhere.
5. Session. A short session timeout limits how long a captured session stays useful.
6. Ownership. Record who owns each integration user in your system and when its access was last reviewed.

A permission set per integration makes this reviewable:

# Before: shared admin login
User: integrations@acme.com
Profile: System Administrator
Used by: ETL tool, marketing sync, support widget

# After: one user per integration, minimum access
User: etl-warehouse@acme.com
License: Salesforce Integration
Profile: Minimum Access - API Only Integrations
Permission set: Warehouse_Sync_Read (Account, Opportunity: Read; 14 fields)
Login IP Ranges: vendor egress range only

#Pairing the user with OAuth

Password-based API logins should be the exception. Two OAuth flows suit system-to-system integrations:

• OAuth 2.0 client credentials flow. The connected app or External Client App is configured with a Run As user, and every token issued acts as that user. Salesforce walks through using it with the Integration user in a developer blog post. The run-as user is the integration's whole identity, so it must be the dedicated, minimum-access user, never an admin.
• OAuth 2.0 JWT bearer flow. The integration signs a token with a private key whose certificate is uploaded to the app, and asserts a username. Restrict the app to admin-approved, pre-authorized users so only the integration user can be asserted.

Either way, the user's permissions are the ceiling. OAuth scopes limit which APIs a token can call; they do not reduce what the user can see once a call is made.

#Monitoring integration users

An integration user has a predictable pattern: same source IPs, same hours, same APIs, no browser. Deviations are the signal.

• Interactive logins. A browser login on an integration account means a person is using it. That is usually a shortcut someone took, and sometimes an attacker.
• New source IPs or a login from an unexpected country.
• Volume changes. A sync that normally reads thousands of records reading millions is worth a look. Event Monitoring log files record API activity for this kind of review.
• Permission changes. Setup Audit Trail shows who added a permission set to an integration user and when.
• Staleness. An integration user that has not logged in for months may belong to a retired tool. Deactivate it and revoke its tokens.

#How Vulkro for Salesforce checks integration users

vulkro-sf org integration-users reads the live org and reports integration and service accounts with too much power or the wrong usage:

vulkro-sf org integration-users --target-org my-prod --format json

It flags SF-INTEG-USER-001 (API access plus admin-level permissions), SF-INTEG-USER-002 (a recent interactive login on an integration account), SF-INTEG-USER-003 (no login for over 180 days), SF-SVC-USER-001 (exempt from MFA and not locked to login IPs) and SF-SVC-USER-003 (Modify All Data, View All Data or Author Apex). Service accounts are matched by name and profile patterns, so review each match before acting. The command docs list every check. For a SOC 2 or ISO 27001 access review, the JSON output is a record of who held what on the day you ran it.

#FAQ

#What is the Salesforce Integration user license?

A license for API-only system users. It provides the Minimum Access - API Only Integrations profile and the Salesforce API Integration permission set license, so you start from minimal access and add only what the integration needs through permission sets.

#Can an integration user log in to the Salesforce UI?

Not on the Salesforce Integration license, which is API-only. On other licenses, assign the API Only User permission to block UI login.

#What permissions should a Salesforce integration user have?

Only the object and field access its API calls need, granted through a dedicated permission set, with no Modify All Data, View All Data or Author Apex, and with login IP ranges set.

See Vulkro for Salesforce and Start a 14-day trial. Related: Salesforce MFA in 2026 and least privilege.