The API Enabled permission lets a user or integration authenticate and call any Salesforce API: REST, SOAP, Bulk, Streaming and Metadata. It is what makes programmatic access possible, which makes it essential to almost every integration and DevOps pipeline. It is also one of the most misunderstood settings in the platform, because it is easy to assume it grants far more than it does.

Here is the part that reframes the whole risk conversation: API Enabled does not grant access to any data. It grants the ability to make API calls. Once a call is made, object permissions, field-level security and record sharing are enforced over the API exactly as they are in the interface. A token can never read or export more than the user it belongs to could see by logging in. The real exposure is not the checkbox. It is the checkbox on a broadly permissioned user.

What Is the API Enabled Permission in Salesforce?

API Enabled is a system permission on a profile or permission set. Salesforce’s documentation states it plainly: a user with API Enabled can access any Salesforce API. That access covers the full set of programmatic entry points, from single-record REST calls to high-volume Bulk API jobs.

What it enables is authentication and invocation. A system holding valid credentials with this permission can open a session and issue API requests. That is the entire scope of the permission itself.

What API Enabled Does Not Do

This is where most of the confusion lives. API Enabled does not change what data a user can reach. Salesforce enforces the same layered access model over the API that it enforces in the UI:

• Object permissions still decide which objects the user can create, read, edit or delete.
• Field-level security still decides which fields come back in the response.
• Record sharing (org-wide defaults, role hierarchy, sharing rules) still decides which records are visible.

So a token belonging to a user with read access to Accounts and Contacts can pull Accounts and Contacts, quickly, and nothing else. It cannot reach Opportunities the user could not see, or fields hidden from that user by field-level security. The API is a faster door into the same house, not a door into a bigger one.

The reason this matters for risk: speed and scope combine. Field-level security and sharing bound what a token can reach; API Enabled removes the human pace that would otherwise limit how fast it reaches it. On a tightly scoped integration user, that is exactly what you want. On an over-permissioned account, it means a compromised credential can extract everything that user could see, in bulk, in minutes. The permission is not the problem. The permission on the wrong user is.

Why API Enabled Is a Compliance and Audit Concern

Once you frame the risk correctly, the compliance exposure is clear. It comes from API Enabled combined with broad object and field access, usually on integration or administrative users, and from the difficulty of seeing what those accounts actually did.

Regulatory frameworks turn that into concrete requirements:

• GDPR: the regulation’s maximum penalty is €20 million or 4% of global annual revenue, whichever is higher. A broadly permissioned, API-enabled account that can read personal data across many records is precisely the kind of over-provisioning a data-minimisation review flags.
• Financial regulations: require auditable change control. Metadata or data moved through APIs without a clear trail of who was granted access and why can produce material-weakness findings.
• Healthcare compliance: requires unique user identification. Shared or over-privileged integration users mask accountability, which is difficult to defend under HIPAA.

The Native Logging Gaps

Salesforce’s native tools cover part of the picture but not all of it. Setup Audit Trail does record the configuration change when a profile or permission set is granted API Enabled, so that moment is captured. Login History records API logins.

The gap is at the call level. Native logging does not record the individual API calls or the row-level content of what they read, and bulk operations roll up into single events, so a job that exported a million records looks much like one that exported ten. To see call-level activity you need Event Monitoring, which is part of Salesforce Shield or available as an add-on. Without it, the questions auditors ask (who had API access, when it was approved, what it was used for) are hard to answer from platform logs alone.

How to Govern API Enabled Permissions

Governance is the same least-privilege discipline you apply to any high-impact permission, aimed at the real risk: keeping API access narrow and keeping the accounts that hold it tightly scoped.

Manual Controls

• Inventory who has it. In Setup, create a custom report type on Permission Set Assignments to list users and their assigned permission sets, and identify every profile and permission set granting API Enabled. Save it as a baseline for drift detection.
• Use dedicated integration users. Give each external system its own login-restricted integration user scoped to only the objects and fields it needs, rather than reusing a person’s account or a shared admin. This is the single most effective control, because it directly limits what any one token can reach.
• Remove the permission from broad profiles. Since a profile applies to whole groups and a permission granted by a profile cannot be muted by a permission set, the permission has to be off at the profile level for granular control to work. Grant API Enabled through narrowly scoped permission sets instead.
• Tighten session boundaries. Add login IP ranges and login hours to integration users so tokens only work from trusted networks during expected windows.
• Require approval for grants. Tie every grant or removal to a ticket or user story so the business justification is traceable at audit.
• Separate sandbox from production. Keep sandbox permission sets distinct so a refresh does not copy elevated API access back into production.

Two common sources of sprawl are worth checking specifically: community and guest profiles that inherited API rights through profile cloning, and some managed packages that install with broad permission sets which may include API access.

Automated Controls in Your Pipeline

Treat every change to API Enabled as code. When profiles and permission sets live in version control, each change passes the same review and traceability gates as any other metadata:

• Pre-merge policy checks that block any diff adding API Enabled unless it references an approved ticket.
• Post-merge scanners that compare the target org’s permission assignments against the manifest and flag unexpected API grants.
• Rollback triggers that revert an offending package and notify security if an unauthorised grant reaches deployment.

For integrations, store credentials in a secrets manager with automatic rotation, so developers do not need standing API access during normal work.

Continuous Monitoring

Pipeline gates catch what flows through the pipeline. Monitoring catches what does not, such as emergency fixes and manual admin changes.

• Nightly drift scans comparing the live org against version control, reporting any untracked API permission a hotfix introduced.
• Quarterly access reviews focused specifically on API-enabled users, to catch business-level over-provisioning.
• Periodic penetration tests against API endpoints, to confirm revoked tokens, IP restrictions and connected-app scopes actually block access.
• Scheduled permission snapshots archived as evidence auditors can verify.

Event Monitoring and Salesforce Shield can stream API call data into a SIEM, but retention, export schedules and anomaly rules have to be configured deliberately rather than assumed on by default.

How to Find Every User with API Enabled

Before you can govern the permission, you need to know who holds it, and it is rarely just the users you expect. It arrives through profiles, through permission sets, through permission set groups, and through managed packages, so a single list is worth building before you change anything.

1. In Setup, open the Object Manager and confirm you can report on Permission Set Assignments, or create a custom report type on that object if one does not already exist.
2. Build a report grouping users by permission set, so you can see every permission set a user holds in one place.
3. For each permission set and profile in your org, check whether API Enabled is granted under System Permissions. Salesforce’s permission set list and the profile detail pages both show this.
4. Cross-reference against your integration users specifically. These are the accounts that most often hold broad object access alongside API Enabled, which is the combination that matters.
5. Note any managed-package permission sets, since some install with broad system permissions that can include API access, and they are easy to overlook because nobody configured them by hand.
6. Save the result as a dated baseline. Future scans compare against it, so drift shows up as a difference rather than requiring a fresh investigation each time.

The output you want is a list of every user who can call the API, the object and field access each of them holds, and the path by which they got the permission. That last column is what tells you whether removing it from a profile will actually take effect, or whether the user will keep it through a permission set.

Common API Enabled Mistakes

Assuming the checkbox equals data access. The most common mistake is the one this article exists to correct. Teams either panic about a permission that, on a scoped user, is low risk, or they ignore object and field permissions because they think API Enabled already decided everything. Govern the account’s data access and the permission together, not the checkbox alone.

Granting it on a broad profile. API Enabled on a widely assigned profile hands programmatic access to everyone on that profile, and because a profile grant cannot be muted by a permission set, you lose the ability to control it granularly. Remove it from the profile and grant it through a permission set.

Reusing a person’s account for an integration. When a human user’s credentials drive an integration, the integration inherits all of that person’s access, the access changes every time their role does, and the audit trail cannot separate human activity from machine activity. A dedicated integration user solves all three.

Letting sandbox refreshes carry access back to production. Elevated API access configured in a sandbox can return to production through a refresh or a metadata deployment if permission sets are not kept environment-specific. This is a frequent source of permissions nobody remembers granting.

Relying on native logs for call-level evidence. Setup Audit Trail shows the grant and Login History shows the logins, but neither shows what an API session actually read. Assuming they do leaves a gap that only surfaces during an incident, when the evidence you need was never being captured. Event Monitoring is what closes it.

Secure API Access with Flosum

API Enabled is essential to the automation that keeps deployments moving. The goal is not to avoid it but to keep it narrow and visible, and to make sure the accounts that hold it stay least-privilege. That is a governance problem, and it is where tooling helps.

Flosum operates entirely inside Salesforce, so permission governance happens without moving metadata to external repositories. It surfaces API-enabled deltas between source and target orgs before a deployment goes live, gates risky permission changes in the pipeline, and keeps immutable audit logs of every grant and removal for forensics and audit evidence. Request a demo to see how it embeds API permission governance into Salesforce workflows without slowing development.

Frequently Asked Questions (FAQ)