Salesforce API Access Control – Part 2 – Enabling It Without Chaos
- Sandeep Supehia
- 22 hours ago
- 3 min read
Continued from Part 1
In Part 1, we broke down why the API Enabled permission can leave your Salesforce data expose and how API Access Control puts a guard at the door.
This Part 2 takes it further: setup, approvals, and the critical pitfalls you need to plan for.
How to set up API Access Control
Request enablement from Salesforce Support
This feature isn’t just a toggle you’ll see in every org. You need to log a case and ask Salesforce to turn on API Access Control for your org.
Go to Setup > API Access Control
Once enabled, you’ll find the setting in Setup.
Pick your restriction option
For admin-approved users, all users can only use APIs through allowlisted Connected Apps.
For customers & partners, external (Experience Cloud) users are restricted to installed Connected Apps.
(Optional) Allow Visualforce to override if you still have VF apps that need APIs.
How to allow (approve/whitelist) apps once API Access Control is enabled?
Here’s the simple flow:
The app isn’t “blocked” by default. Here’s what actually happens:
When you turn on API Access Control (the setting in Setup), Salesforce automatically flips all Connected Apps in your org to the policy: “Admin-approved users are pre-authorized.”
That means until you explicitly assign profiles/permission sets to an app, no one can use it. From the user’s perspective, it looks like the app is “blocked.”
On the Connected Apps OAuth Usage page, that’s why you sometimes have to Unblock an app “Unblock” basically means “approve this app for API use and assign it to users.”
Most Important part, key considerations after enabling API Access Control
All apps are restricted by default
As soon as you enable it, every Connected App in your org flips to Admin-approved users are pre-authorized.
Users will suddenly lose access unless you quickly assign profiles/permission sets to re-allow the right apps.
Common Salesforce apps are included
Even Salesforce’s own apps (Salesforce Mobile, Outlook integration, etc.) become “blocked” until you explicitly approve them.
Make a checklist of the core apps your teams depend on and allowlist them first.
Your users even won’t be able to access Salesforce Support or Trailhead. External logins may fail if their Connected App (e.g. tbid.digital.salesforce.com) is not allowlisted.
You’ll need to review Experience Cloud apps and unblock the right ones.
Developer Console stops working
Because it runs on REST API, you’ll see “This session is not valid for use with the REST API.”
Workaround: Temporarily assign Use Any API Client permission to Admins, or (better) move them to VS Code / CLI.
Extra admin overhead
Every new integration will require admin approval and assignment before it works.
That’s by design but you need clear SOPs so business users know to request app access instead of raising urgent tickets when “nothing works.”
Not a silver bullet
If credentials are stolen and the user has access to an approved app, the hacker can still log in.
That’s why you still need MFA, SSO, IP restrictions, and good offboarding practices.
Think of API Access Control as moving from a wide-open gate to a guarded entry point. It adds some admin overhead and might come with business impact, but in return you know exactly who and which apps are touching your Salesforce data.
Don’t leave Salesforce wide open. API Access Control won’t solve everything but it transforms your security posture from guesswork to guardrails.
Audit your Connected Apps. Lock the API door. Own your risk surface.
If you want a blueprint that balances speed and security, Truffle can help you move fast without breaking trust.
Contact Truffle Consulting:
E-mail us: hello@trufflecorp.com
Fill out our reachout form: https://www.trufflecorp.com/contact-us
Comments