Salesforce Integration user license: cost, limitations, setup steps and the profile it uses

What is a Salesforce Integration user license?

A Salesforce Integration user license is a user license type intended only for system-to-system integrations. A user holding one authenticates and calls the Salesforce APIs, and that is all it can do: it cannot access the org through the user interface or view Salesforce data there. Salesforce introduced it so that the account a middleware platform or custom script logs in as does not have to be a full user with a full user's reach.

The practical effect is a smaller blast radius. A credential that leaks from a CI pipeline or a vendor configuration screen can be used to call APIs within whatever permission sets you granted, and it cannot be used to sign in and browse the org. It also separates the audit trail: when a record shows an unexpected change, "last modified by NetSuite Sync" answers the question immediately in a way that "last modified by the ops director" never does.

How many free Salesforce Integration user licenses do you get?

Enterprise, Unlimited and Performance orgs are provisioned five at no additional cost, and Developer Edition orgs get one. They are usually already sitting in Setup under Company Information, unclaimed, in orgs that are paying for a full license to run a nightly sync.

Free Salesforce Integration user licenses by edition

Edition	Free Integration user licenses	What to know
Enterprise	5	Provisioned automatically. No request, no order form, no extra cost
Unlimited	5	Same allocation as Enterprise
Performance	5	Same allocation as Enterprise
Developer Edition	1	Enough to build and test an integration against
Professional and below	Not provisioned	API access itself is an add-on on Professional, so check that first

Check before you buy anything: Setup, Company Information, then the User Licenses table. If Salesforce Integration shows five total and zero used, you have five integrations' worth of licensing already paid for.

How much does a Salesforce Integration user license cost?

The first five cost nothing on Enterprise, Unlimited and Performance, and the first one costs nothing on Developer Edition. Beyond that allocation they are sold as an add-on, priced per user per month and materially cheaper than a full Salesforce license, because the license grants no interface access to pay for. Salesforce does not publish a public list price for the add-on, so treat any number you find in a blog post as an estimate and get the figure from your account executive.

The cost worth modeling is not the license anyway. It is what happens when you skip it: a full license consumed by a service account, or an integration authenticated as a person, which turns an ordinary offboarding into an outage nobody diagnoses for a day.

What can and cannot a Salesforce Integration user do?

Salesforce Integration user license capabilities and restrictions

Capability	Allowed	What to know
Call the Salesforce REST, SOAP and Bulk APIs	Yes	This is the entire purpose of the license
Read and write records via API	Yes	Scoped by the permission sets you assign, not granted by default
Sign in to the Salesforce user interface	No	The user cannot access the org directly or view data in the UI
Run reports and dashboards in the UI	No	Follows from having no interface access at all
Hold Visualforce page permissions	No	Permission sets on this license cannot contain Visualforce pages
Hold Lightning Experience user permissions	No	Excluded for the same reason. There is no interface for it to apply to
Deploy arbitrary metadata	Partly	Standard and custom objects and fields are workable. Broader metadata deployment usually needs permissions that defeat the point of a restricted license

Note that object access is not granted by the license. The license establishes what kind of user this is; permission sets built on the Salesforce API Integration permission set license decide which objects and fields it can touch. A new integration user with no permission sets can authenticate and read almost nothing, which is the correct starting point.

How do I set up a Salesforce Integration user?

Five steps, and the second one is where most first attempts go wrong. Assign the permission set license before you try to assign permission sets built on it.

Which profile does a Salesforce Integration user use?

The Salesforce API Only System Integrations profile, which ships with the license. It is the counterpart to the old practice of cloning a Standard User profile and stripping it down by hand, and it is better because it starts from nothing rather than from everything. Layer object access on top through permission sets rather than by editing the profile, so that two integrations with different needs do not end up sharing one over-permissioned profile.

What are the limitations of the Salesforce Integration user license?

Limitations of the Salesforce Integration user license and their practical impact

Limitation	What it means in practice
No user interface access at all	You cannot log in as this user to check what it can see, which makes permission debugging slower than it is for a normal user
Permission set license must be assigned first	Permission sets built on the Salesforce API Integration license will not attach to a user who does not already hold it
No Visualforce or Lightning Experience permissions	Any tool that expects to render a page as this user will not work
Metadata deployment is awkward	Deployment tools often need permissions broad enough that the security benefit of the restricted license mostly disappears
Five is a real ceiling	Past five integrations you either buy more licenses or start sharing one across systems, which costs you the traceability you set this up for
It does not raise your API allocation	The daily call limit belongs to the org, not the user. Adding integration users does not add calls

The metadata one deserves a warning. Release management and deployment tools frequently need permissions well beyond object access, and granting them to an integration user recreates the over-permissioned account you were trying to avoid. For deployment tooling, a dedicated full license is often the more honest answer than an integration license with Modify All Data bolted onto it.

Do I need one integration user per integration?

Yes, if you can afford the licenses, and you probably can within the free five. One user per integration is what makes a problem diagnosable. When the daily API allocation is suddenly 90 percent consumed by 11 AM, the API usage report tells you which user spent it, and that only helps if the users map one to one onto systems. Share a single account across four vendors and the report tells you nothing you did not already know.

The same logic applies to record history. If a nightly job overwrites a field it should not have touched, "last modified by Marketing Sync" isolates the culprit in one click. If every integration writes as the same generic API user, you are reading vendor logs instead. In regulated environments this stops being convenience and starts being evidence, which is why it helps to have the access controls you rely on mapped to the obligations they satisfy rather than rediscovered during the audit.

Does an integration user increase my Salesforce API limits?

No. Daily API call allocations belong to the org, not the user. Enterprise and Professional orgs get 100,000 calls per 24 hours plus 1,000 per Salesforce license, and Unlimited and Performance get 100,000 plus 5,000 per license. Developer Edition gets 15,000 and a full sandbox gets 5,000,000. Adding integration users changes none of that. It changes who you can blame, which is genuinely valuable, but the pool is shared.

The ceiling that catches teams out is a different one: only 25 requests lasting 20 seconds or longer can run concurrently in a production org, and only 5 in a Developer or trial org. A vendor that fires off long-running queries in parallel can exhaust that while your daily allocation still looks healthy. The full set of allocations is tabled on Salesforce integration tools, alongside the platforms that live inside them.

What happens if you run an integration as a regular user instead?

Three things, in roughly this order. First, the integration inherits every permission that person has, so a credential leak reaches far more than the four objects the sync needed. Second, record history and audit logs attribute machine writes to a human, which makes any investigation slower and occasionally points at the wrong person. Third, and most commonly, the integration breaks during an ordinary HR process: role change, permission cleanup or deactivation. Nobody connects the two events, so a data team spends a morning debugging a pipeline that is working exactly as designed.

That third failure is the one worth pricing. It costs a morning the first time and a reputation the second time, when the number on a board slide turns out to have been stale for a week.

Integration user license or full Salesforce license?

Use the Integration user license when the account only ever calls APIs, which covers almost every middleware platform, ELT connector and custom script. Use a full license when the account genuinely needs interface access: deployment and release tooling, anything that renders a Visualforce page, or a tool whose support process starts with "log in as that user and show us the screen". Trying to force the second category onto a restricted license produces a long tail of permission errors and eventually a license with so many extra permissions that it is a full user in all but name.

Where this fits in a working integration

The integration user is step one of about five. After it come the API choice, which should be Bulk API 2.0 for anything above a few thousand records, the field mapping, the conflict rule for records both systems can edit, and an external ID so that updates upsert instead of creating duplicate Accounts. Each of those decisions outlives the tool you make it in, which is the argument for writing them down somewhere other than a vendor's configuration screen.

If the destination is a warehouse, the specific object mapping is covered in syncing Salesforce to Snowflake and Salesforce to Postgres. If it is another business application, iPaaS platforms covers that category, and API integration software covers how our own connector authenticates and retries.