Hey friends,
Salesforce has one API for each kind of job, and you choose by how many records you're moving, whether the caller can wait and which direction the data flows. Use the REST sObject resources for single records, Composite when you need several operations in one call, Bulk API 2.0 for anything over about 2,000 records, SOAP when a tool or WSDL requires it, Apex REST when you need custom logic, and Pub/Sub API for events.
This page is the map. I link to deeper posts on the REST API, SOAP API, Bulk API 2.0, Composite API and platform events. Choosing the right API is part of the Design section of the Salesforce Certified Platform Integration Architect exam, which is the biggest section at 28%.
What are the main Salesforce APIs?
Salesforce's own API developer blog post compares them. Here's the short version, using that post's numbers:
| API | Use it for | How it behaves |
|---|---|---|
| REST sObject resources | Create, read, update or delete one record at a time, and walk relationships | One request is one call against your API limit |
| REST Query | Run a SOQL query | Returns up to 2,000 records at a time, then a query locator for the rest |
| REST Composite family | Several operations in one request | Composite takes up to 25 subrequests, composite graph up to 500, sObject collections up to 200 records for writes |
| SOAP API | Tools and systems built on a WSDL | Up to 200 records per request, query pagination of 2,000 records |
| Bulk API 2.0 | Ingesting, extracting or deleting large data sets | Asynchronous, one object per job, no completion SLA, not ideal for small workloads |
| Apex REST and SOAP | Exposing your own Apex class as an endpoint | Custom, so Apex governor limits apply on top of API limits |
| Pub/Sub API | Publishing and subscribing to platform events and change data capture events | gRPC and binary Avro messages |
| Metadata API | Moving configuration, not records, between orgs | Deploys, retrieves, creates, updates or deletes metadata such as custom object definitions and page layouts |
| UI API and GraphQL API | Custom user interfaces that need data and metadata | Not for system-to-system data loads |
How do I choose an API by data volume?
For a non-UI integration, the volume decides it. The Salesforce post gives this rule of thumb:
- One record at a time: the REST sObject Rows resource.
- Tens to thousands of records written: the REST Composite API.
- Retrieving a few to thousands of records: the Query resource.
- Large amounts of data, generally more than 2,000 records: Bulk API 2.0.
The Bulk API documentation says the same from the other side: any data operation with more than 2,000 records is a good candidate for Bulk API 2.0, while jobs with fewer than 2,000 records should use bulkified synchronous calls in REST, for example Composite, or SOAP. Because the Bulk APIs are asynchronous, Salesforce doesn't guarantee a service level agreement for them.
If you learn best by testing yourself, the Platform Integration Architect Cert Lab has quick practice questions on choosing the right API, with every option explained.
What does a REST API call look like?
Every REST call goes to your My Domain URL, under /services/data/vXX.X/, with a bearer token. Creating an Account and then reading it back looks like this:
The query resource takes a URL-encoded SOQL string, as the REST API query documentation shows. I cover upserts, queries and custom Apex endpoints in the Salesforce REST API post.
When is Composite better than separate REST calls?
When one business action takes several calls and you want fewer round trips. The post lists five composite resources:
| Resource | What it does | Limits from the post |
|---|---|---|
| Composite | A series of subrequests where one can use another's output | 25 subrequests, 5 of them queries or collections, with allOrNone |
| Composite graph | Several independent graphs in one call, each all or nothing | 75 graphs, 500 subrequests in total, sObjects only |
| Composite batch | Independent subrequests | 25 subrequests, each commits when it succeeds, and each counts toward API limits |
| sObject tree | A tree of nested parent and child records | 200 records across five types, five levels deep |
| sObject collections | CRUD on many records of one or more types | 200 records for writes, 2,000 for reads |
One detail worth knowing for the exam: composite batch subrequests are independent and don't roll back each other, while composite and composite graph can be all or nothing. I go through each one, with the 25 and 500 subrequest limits, in Salesforce Composite API.
Is SOAP API still worth knowing?
Yes, because plenty of enterprise tools still speak it. I cover it on its own in Salesforce SOAP API and WSDL. SOAP API works on org-specific and org-agnostic WSDLs and handles data, metadata and utility operations. Two things to remember. First, Salesforce commits to supporting each API version for at least three years from first release, and gives at least a year of notice before ending support, per the SOAP API end-of-life policy. Second, that same page says the SOAP login() call is scheduled for retirement in Summer '27, so new integrations should authenticate with OAuth instead.
Which API should I use for events?
Pub/Sub API is the newer way to publish and subscribe to platform events and change data capture events, based on gRPC and HTTP/2. Before it existed, the only way to subscribe from an external client was Streaming API. The Streaming API vs. Pub/Sub API page compares them:
| Streaming API | Pub/Sub API | |
|---|---|---|
| Event encoding | JSON | Binary (Apache Avro) |
| Protocol | CometD (Bayeux) | gRPC and protocol buffers |
| Subscription model | Push: the server delivers events as they arrive | Pull: the client asks for a number of events |
| Flow control | The client can't control how many arrive | The client says how many to receive per Subscribe call |
| Publish result | Not supported | The final publish result is returned |
Platform events themselves, with their allocations and replay, get their own page: Salesforce platform events.
What about the Metadata API and middleware?
Two things people confuse with the record APIs. The Metadata API works on configuration, not business data. Salesforce says its main purpose is moving metadata between orgs during development, and to create, retrieve, update or delete records such as accounts or leads you use SOAP API or REST API instead.
Middleware is a design choice, not an API. The exam guide says candidates will likely need help picking the best-choice middleware tool in a given scenario, so the exam is more interested in why you'd put something between Salesforce and another system than in product names. My own rule of thumb: add middleware when you need transformation, routing, retries or a place to monitor many connections, and skip it when one system calls another in a simple way.
How do API callers authenticate?
With OAuth 2.0 through an external client app. Per the Salesforce OAuth flows documentation, all flows except the SAML assertion flow require an external client app. For server-to-server work, two flows matter most:
- JWT bearer flow: the server signs a request with a certificate, no user interaction, but the client app has to be approved beforehand.
- Client credentials flow: the app swaps its consumer key and secret for a token, and you name an integration user to run the integration. Salesforce calls it a more secure alternative to the username-password flow.
- Username-password flow: Salesforce recommends avoiding it because it passes credentials around, and it's blocked by default in orgs created in Summer '23 or later.
Which calls count against my API limits?
Most single requests count as one call. The notable exception in the Salesforce post is composite batch, where each subrequest counts toward your limits. A composite request, a graph, a tree or a collections call counts as one call no matter how many records it carries. That's one reason Composite and Bulk save API calls in busy orgs.
How do API types show up on the exam?
Expect a scenario with a volume and a timing, such as "a nightly load of five million records" or "a mobile app that needs one account when a rep taps it", and four APIs as options. Match the volume first, then check for events, custom logic or a WSDL requirement. My longer notes on patterns are in the integration patterns post.
A bit about how I study. Focus on Force was my favorite resource on the way to 17 Salesforce certs. I started the traditional way, reading the study guide first and testing second, but rapid-fire practice tests are what actually made things stick. That's the loop Cert Lab is built on: quick questions, then explanations with current links, then go again.
FAQ
What are the main types of Salesforce API?
REST API, SOAP API, Bulk API 2.0, the Composite resources, Apex REST and SOAP services, Pub/Sub API and the UI and GraphQL APIs for custom user interfaces.
When should I use Bulk API 2.0?
For operations on more than about 2,000 records. It's asynchronous and has no completion SLA, so it isn't for anything a user is waiting on.
What is the difference between REST and SOAP API in Salesforce?
REST works with resources and JSON under /services/data. SOAP is WSDL-based, handles up to 200 records per request and is common in older enterprise tools. SOAP login() is scheduled for retirement in Summer '27.
What is Pub/Sub API?
A gRPC-based API for publishing and subscribing to platform events and change data capture events, using binary Avro messages and a pull-based subscription model.
Does Composite API reduce API calls?
Yes. A composite, graph, tree or collections request counts as one call. Composite batch is the exception, because each subrequest counts.
Where should you go next?
- Salesforce REST API for upsert, query and Apex REST.
- Salesforce Bulk API 2.0 and Composite API for loads and write limits.
- Salesforce platform events for the event-driven side.
- Salesforce integration basics if you're newer to integration.
Nick Frates, a senior Salesforce developer with 17 certifications, built the Platform Integration Architect Cert Lab at nickfrates.com: rapid-fire practice questions for every exam section, each answer explained.
Cert Lab by Nick Frates
Let the Platform Integration Architect Cert Lab test you to success
Lessons, flashcards, a quiz for each of the six exam sections and full practice exams, every answer explained.
Start the Platform Integration Architect Cert Lab for $9.99 →Not ready to buy? Try a free lesson and see how fast you learn.
Hope this helps!
Best,
Nick


