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.
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.
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.
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.
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.
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.
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 →Both let external systems work with Salesforce data. REST uses JSON and lightweight HTTP calls, which is why almost all new integration work uses it. SOAP uses XML and a formal WSDL contract, and it still shows up in older integrations or specific enterprise scenarios that were built before REST became the default choice.
Not a static one. Salesforce authenticates API access through OAuth 2.0 and a Connected App you set up in your org, which issues tokens rather than a single permanent key. That's more setup upfront, but it means access can be scoped and revoked without resetting a shared secret everywhere it's used.
Salesforce bumps the version number with each of its three yearly releases (Spring, Summer, Winter), so by 2026 it's well into the 60s. The exact number matters less than you'd think since Salesforce keeps older versions working for years, so an integration doesn't need updating every release just to stay functional.
Yes, through Salesforce's own Einstein Activity Capture or the older Salesforce for Outlook add-in, which sync email and calendar activity between the two. It doesn't push full record data both ways, so anything beyond logging activity, like surfacing account details inside Outlook, needs a custom build on top of the API.
A handful of major platforms have a native Salesforce connector that handles the basics. Most project management tools don't, and connecting them means a custom integration against both APIs, which is also where you get to decide exactly which fields and statuses actually need to sync instead of accepting whatever a generic connector maps.