Salesforce Has a Real REST API. Here's What It Actually Connects To.
Salesforce's REST API lets any external system read, create, update, or delete records in your org over plain HTTPS calls, using JSON and OAuth 2.0 for authentication. It's versioned (Salesforce ships a new one three times a year and keeps old ones working for years), it covers standard objects like Accounts and Opportunities along with anything custom you've built, and it's the same API most AppExchange connectors and custom integrations are built against. We build against it, and against Salesforce's other APIs, to connect your org to whatever else your business runs that it doesn't already talk to.
What the Salesforce REST API actually covers
Every call goes to a versioned endpoint, something like `/services/data/v62.0/`, and that version number matters less than people expect. Salesforce adds a version with each release but keeps supporting old ones for years, so an integration built against an older version doesn't just stop working the next time a release rolls out.
You can query records with SOQL through the same API, run standard create/read/update/delete calls against any object, and reach custom objects exactly the way you'd reach a standard one. For large jobs, moving tens of thousands of records at once, the Bulk API handles it asynchronously instead of making you fire off calls one at a time.
The older SOAP API still works too, and some long-running integrations are still built on it, but almost everything new goes through REST now. Either way, there's no permanent static API key to copy and paste. Access runs through a Connected App and OAuth tokens, which is the part most people building their first integration get stuck on, not the data calls themselves.
Where the real gap sits
The API itself is comprehensive. The actual work is building and maintaining the integration against it, and that's a different problem for every pair of systems. Outlook has an official Salesforce integration (Einstein Activity Capture or the older Salesforce for Outlook), but it syncs email and calendar activity, not full records, so anything beyond that still needs custom work. Project management tools are a mixed bag: a few major ones have native Salesforce connectors, most don't, and "salesforce and project management" as a search is really someone discovering that gap firsthand.
Rate limits are real too. Each Salesforce edition gets a daily API call allowance, and a high-volume integration can bump into it if nobody's watching. And every so often the system on the other end of an integration, an older vendor portal, a distributor's order site, a tool that predates its own API, simply doesn't have one. When that's the actual limitation, we build against the system's screens directly with headless-browser automation instead of waiting for an API that isn't coming.
What we build with Salesforce's API
One form submission, one clean record
A lead fills out a form on your site and a direct API call creates the Salesforce lead within seconds, with campaign source and UTM data mapped into the right fields instead of dumped into a single notes field the way a generic form connector often leaves it.
Syncing a tool with no Salesforce listing
A niche ticketing or scheduling tool with no AppExchange presence still needs to stay in step with Salesforce. We build directly against both systems' APIs so a status change on one side updates the matching record on the other, no manual re-entry required.
What's not connected to Salesforce right now?
A tool with no native connector, a partner portal you're still exporting from by hand, a system with no API at all: tell us what it is and we'll scope what's actually possible.
Stuck re-entering the same record in Salesforce and somewhere else?
Tell us which two systems and what's getting typed twice. Salesforce's API is just one example of what we build against, any tool your business runs, API or not, is fair game for the same treatment.
Let's talk