The Salesforce API is a family of web APIs that let other systems work with Salesforce. REST API reads and writes records, SOAP API does the same with a strict WSDL contract, Bulk API 2.0 handles large data loads, Pub/Sub API streams real-time events, and Metadata API moves configuration between orgs. Most integrations need only two or three of them; this guide shows which.
This guide was first published in 2020 as "Salesforce API Developer Guide". It has been rewritten for 2026 with the current API line-up, limits, and the authentication changes coming in 2026 and 2027.
The Salesforce APIs at a glance
As of November 2026, Salesforce offers ten main APIs, from REST and SOAP for records to Pub/Sub for events and Metadata for deployments. Trailhead's Platform API Basics unit lists the APIs, their protocols and their typical uses. Summarised:
| API | Protocol and format | Sync or async | Use it for |
|---|---|---|---|
| REST API | REST; JSON or XML | Synchronous | Web and mobile apps, middleware, most record-level integrations |
| SOAP API | SOAP with WSDL; XML | Synchronous | Server-to-server integrations that want a typed contract |
| Bulk API 2.0 | REST; CSV | Asynchronous | Loading, updating, deleting or extracting large numbers of records |
| Pub/Sub API | gRPC with Avro messages | Asynchronous stream | Real-time events: platform events and Change Data Capture |
| Metadata API | SOAP; XML | Asynchronous | Deploying and retrieving configuration and code between orgs |
| GraphQL API | GraphQL; JSON | Synchronous | Fetching exactly the fields and related records a client needs in one call |
| Tooling API | REST or SOAP | Synchronous | Building developer tools; querying metadata with SOQL |
| User Interface API | REST; JSON | Synchronous | Custom UIs that respect layouts and admin changes |
| Connect REST API | REST; JSON or XML | Synchronous | Chatter feeds, Experience Cloud sites, CMS content, B2B Commerce |
| Apex REST | REST; custom | Synchronous | Exposing your own Apex logic as an endpoint |
Which Salesforce API should you use?
Use REST API by default, Bulk API 2.0 for large volumes, Pub/Sub API for change events and Metadata API for deployments.
- Create, read, update or delete a few records at a time: REST API. It is the default choice for almost every new integration and for middleware such as MuleSoft.
- More than about 2,000 records: Bulk API 2.0. Salesforce's Bulk API 2.0 guide uses 2,000 records as the rule of thumb and recommends Bulk API 2.0 over the original Bulk API, which is still supported but no longer enhanced.
- React when something changes in Salesforce: Pub/Sub API subscribed to Change Data Capture or platform events, instead of polling every few minutes.
- Move configuration between sandboxes and production: Metadata API, usually through the Salesforce CLI or a DevOps tool rather than directly.
- A screen that needs an account, its contacts and open opportunities together: GraphQL API, which returns them in one request.
- Logic that must run inside Salesforce before data is saved: an Apex REST endpoint you write, with your own validation and transactions.
- A legacy system that only speaks SOAP: SOAP API, with OAuth for login (see the changes below).
For the bigger picture, such as when to sync data, when to call out in real time and when to use middleware, see our Salesforce integration patterns guide.
REST API: the default for record integrations
REST API is the simplest way to read and write Salesforce records from another system. It works over HTTPS with JSON. Resources follow a simple pattern: /services/data/vXX.X/sobjects/Account/ to create or describe records, /query?q= for SOQL, and composite resources to send several operations in one round trip, which saves API calls. Winter '27 ships API version 68.0, and Salesforce's Winter '27 developer notes say you can put latest in the version segment to reach the newest version your org supports. In production integrations, pin a version number so a release cannot change behaviour unexpectedly.
SOAP API, and the login() retirement
SOAP API is still supported, but its password-based login() call is being retired between December 2026 and Summer '27. SOAP API covers much the same ground as REST API, with a WSDL contract that generates typed classes in Java or .NET. Its login() call, which exchanges a username and password for a session, is being retired. According to Salesforce's retirement article and its release notes:
login()is not available from API version 65.0 (Winter '26).- From 1 December 2026, users who authenticate with SOAP
login()need the Use Any API Auth permission. - From 15 December 2026 (sandboxes) and 31 January 2027 (production),
login()from very broad IP ranges needs a security token or mutual TLS. - With the Summer '27 release,
login()is retired in API versions 31.0 to 64.0.
The fix is the same in every case: move the integration to OAuth 2.0 through an external client app. If you have older integrations, find them now: Salesforce points to Login History and the API Total Usage event log to see which applications still call login().
Bulk API 2.0 for large volumes
Bulk API 2.0 is the API for loading or extracting thousands to millions of records asynchronously. It works in jobs. For an ingest job you create the job, upload a CSV file, mark the upload complete, and Salesforce splits and processes the data in the background; you then download the successful and failed rows. Query jobs run a SOQL query and return CSV results, though some clauses, such as GROUP BY, OFFSET and aggregate functions, are not supported. Data Loader and the CLI's sf data import bulk use Bulk API under the hood, so you rarely need to call it by hand; see our Data Loader guide and data migration strategies.
Pub/Sub API and events
Pub/Sub API is the modern way to subscribe to, and publish, Salesforce events over gRPC. Use it with Change Data Capture, which emits an event whenever a record is created, updated, deleted or undeleted, or with platform events you define yourself. Salesforce's streaming event comparison describes PushTopic and generic events as legacy products that get no new features; Pub/Sub API does not support them (nor standard-volume platform events), so new designs should use Change Data Capture and platform events instead.
Metadata API and Tooling API
Metadata API moves configuration between orgs; Tooling API powers developer tools. Metadata API deploys and retrieves configuration, such as objects, fields, flows, profiles and Apex, as XML files. It is what change sets, DevOps tools and the CLI's sf project deploy start rely on. Tooling API is for developer tooling: querying Apex classes, running tests or reading debug logs. Neither is meant for business data. Our Salesforce DevOps guide covers how deployments fit together.
Authentication, editions and limits
Every call needs OAuth, the org's edition must include API access, and calls count against a rolling 24-hour allocation.
Authentication. Every API call needs an OAuth access token (or a session). For server-to-server integrations, set up an external client app with an OAuth 2.0 flow that needs no stored password, and give the integration user only the permissions it needs; our Salesforce security guide covers least privilege.
Editions. API access is enabled by default in Enterprise, Unlimited, Performance and Developer editions, according to the REST API guide. Professional Edition needs API access bought as an add-on, and each user also needs the API Enabled permission. See our editions comparison.
Limits. API requests are counted per org over a rolling 24 hours, not per user. Salesforce's limits reference gives the formula as a base allocation plus calls per user licence plus any purchased add-ons: an Enterprise Edition org with 15 Salesforce licences gets 115,000 requests (100,000 plus 15 × 1,000). Past the limit, calls fail with REQUEST_LIMIT_EXCEEDED until usage drops. Track usage in Setup or the Sforce-Limit-Info response header, and inside Apex watch the separate governor limits.
How to get started with the Salesforce API
You need an org, an integration user, an external client app for OAuth, and a tool to send requests.
- Get an org. Sign up for a free Developer Edition or use a sandbox; never experiment in production. Our guide to creating a Salesforce developer account walks through it.
- Create an integration user with the API Enabled permission and only the object access the integration needs.
- Create an external client app in Setup and enable an OAuth 2.0 flow; it gives you the consumer key and secret that replace the old "API key" idea.
- Make a first call. Request an access token, then call
/services/data/v68.0/limitsor run a simple SOQL query. Postman, Workbench or the Salesforce CLI all work. - Monitor usage in Setup (System Overview or Company Information) or through the REST API Limits resource before you go live.
Common mistakes with the Salesforce API
Most API problems come from using the wrong API for the volume, or from weak authentication.
- Using REST for bulk loads. Looping single-record calls over 50,000 records burns the daily allocation; use Bulk API 2.0 or composite requests.
- Polling for changes. A job that queries every minute for updates wastes calls and still lags; subscribe to Change Data Capture.
- A shared admin login for integrations. Use a dedicated integration user with minimal permissions and OAuth.
- Ignoring the order of execution. API writes fire triggers, flows and validation rules like any other save; see our order of execution guide.
- No error handling for partial success. Bulk and composite calls can succeed for some records and fail for others; read the failed results and retry them.
To try any of these APIs safely, use a free Developer Edition org or a sandbox, and explore calls with Workbench.
Getting help
Picking the right API is the easy part; designing for limits, failures and security is where integrations succeed or break. Techila is a Salesforce Summit Partner; our Salesforce integration services team designs and builds API integrations and MuleSoft solutions. Talk to us about connecting Salesforce to your systems.
Frequently asked questions
What is the Salesforce API?
It is a set of web APIs that let other systems read and change Salesforce data, listen for events and manage configuration. The main ones are REST API, SOAP API, Bulk API 2.0, Pub/Sub API, Metadata API and GraphQL API, each suited to a different kind of integration.
Which Salesforce API should I use?
Use REST API for reading and writing records from web, mobile or middleware apps; Bulk API 2.0 for jobs of more than about 2,000 records; Pub/Sub API to react to changes in real time without polling; Metadata API to move configuration between orgs; and GraphQL API when a client needs several related records in one request.
Is the Salesforce API free?
API access is included at no extra cost in Enterprise, Unlimited, Performance and Developer editions. Professional Edition needs it bought as an add-on. Every org has a daily allocation of API calls, and more calls can be bought.
How many API calls does Salesforce allow?
Allocations are per org over a rolling 24 hours. For Enterprise Edition the base is 100,000 calls plus a number per user licence, for example 1,000 per full Salesforce licence. Check Setup, the Sforce-Limit-Info response header or the REST API limits resource for your org's figure.
Is Salesforce SOAP API being retired?
SOAP API itself is not, but its login() call is. It is unavailable from API version 65.0 and Salesforce is retiring it in versions 31.0 to 64.0 with the Summer '27 release. Move integrations that log in with a username and password to OAuth 2.0 with an external client app.