Application Programming Interface (API)
An Application Programming Interface (API) is a defined contract that lets one piece of software call another without knowing how it is built inside.
Definition
An Application Programming Interface (API) is a defined contract that lets one piece of software call another without knowing how it is built inside. In Salesforce, the word API usually points to one of the platform's standard web service interfaces, such as REST API, SOAP API, Bulk API 2.0, Pub/Sub API, GraphQL API, Connect REST API, User Interface API, Metadata API, and Tooling API. It can also mean a custom Apex REST or Apex SOAP endpoint that a developer exposes from an org.
Each Salesforce API speaks a particular protocol and data format, covers a particular set of operations, and carries its own authentication and limits. REST and Bulk use HTTP and JSON, SOAP uses XML over a WSDL contract, and Pub/Sub uses gRPC with binary Apache Avro payloads. APIs are how an org reads and writes data with the systems around it, whether that is a mobile app, a data warehouse, an ETL job, or another cloud.
Picking the right Salesforce API for the job
REST API, the modern default
REST API is the lightweight, web based interface that most new Salesforce integrations start with. It supports JSON and XML, runs over HTTP, and handles synchronous create, read, update, and delete work against standard and custom objects. Salesforce documentation recommends it for mobile and web applications that need simple, direct interaction with records. Endpoints follow a versioned pattern under /services/data/vXX.0, so a call to read an Account hits /services/data/vXX.0/sobjects/Account/{Id}. Authentication is handled through OAuth, and in Apex the secrets sit behind a Named Credential so they stay out of code and metadata. REST also includes a Composite family that bundles several related requests into one round trip, which cuts both latency and API consumption. The pattern to follow is straightforward. Reach for REST first, prove it covers the use case, and only move to a heavier API when REST genuinely does not fit. Most integration work is ordinary CRUD on a handful of objects, and for that the REST API is the cleanest, best documented, and easiest to debug option on the platform.
SOAP API for formal, legacy contracts
SOAP API is the older, XML based interface built around an industry standard protocol and a WSDL contract. Salesforce still fully supports it, and Trailhead positions it for server to server integrations that need a formal specification, often connections to ERP or finance systems that already speak SOAP. The functional surface overlaps heavily with REST, so SOAP can do the same record level work. The difference is weight. XML envelopes are verbose, the WSDL adds ceremony, and tooling tends to be older. For brand new development the guidance is to default to REST and treat SOAP as the right answer mainly when an existing system or vendor library is already SOAP based. SOAP also has a quiet but important role for asynchronous jobs. Bulk API does not provide its own login operation, so a Bulk client first authenticates through SOAP API to obtain a session before submitting jobs. Knowing SOAP still matters because thousands of mature integrations were built on it, and they keep running long after the teams that wrote them have moved on.
Bulk API 2.0 for high volume data
Bulk API 2.0 is the asynchronous, REST based interface for moving large data sets in and out of Salesforce. You submit a job, Salesforce processes the records in the background, and you return later to collect the results rather than waiting on a single open request. It is built to insert, upsert, update, delete, and query data at volumes that would overwhelm row by row REST calls, and Salesforce guidance points to it once a load climbs into the tens of thousands of records and beyond. Bulk API 2.0 is the recommended choice for new bulk work because it has a simpler interface than the original Bulk API 1.0. It manages its own batching internally, so the client uploads the full data set and lets the platform split the work. Data Loader and many ETL platforms use Bulk under the hood, which is why a nightly sync of a million records does not consume a million individual API calls. When throughput matters, switching a tight REST loop to a Bulk job is usually an order of magnitude improvement in both speed and limit consumption.
Pub/Sub API for events in near real time
Pub/Sub API is the event interface for systems that need to know about Salesforce changes as they happen instead of polling on a timer. Official docs describe it as a single interface for publishing and subscribing to platform events, change data capture events, and real time event monitoring events. It is built on gRPC and HTTP/2, and it delivers binary event messages encoded in Apache Avro, which keeps payloads compact and fast. A subscriber opens a stream, receives change events as records are modified, and can also publish events back into Salesforce over the same channel. Pub/Sub API is the newer successor to the older Streaming API, which used CometD long polling, and it is the recommended path for new event driven integrations. The practical win is decoupling. An external order system can react to a closed Opportunity the moment it closes, without a scheduled job scanning for changes every few minutes. That lowers load on the platform, shrinks the gap between an event and the reaction to it, and scales far better than polling as data volume grows.
GraphQL, Connect REST, and the UI API
Beyond the core data APIs, Salesforce ships several interfaces aimed at specific surfaces. GraphQL API lets a client ask for exactly the fields it wants in a single query, so a mobile screen can pull a precise slice of related records without over fetching or chaining many REST calls. Connect REST API exposes higher level features such as Chatter feeds, Experience Cloud sites, CMS managed content, and B2B Commerce, which is useful when you are building social or community experiences rather than raw record access. User Interface API powers native mobile and custom web clients by returning records together with the layout and metadata needed to render them, so a custom app can match Salesforce page behavior without hard coding field lists. Analytics REST API reaches datasets, lenses, and dashboards. Each of these is purpose built. The skill in integration design is matching the interface to the use case, picking GraphQL for selective reads, Connect REST for feeds and content, and the UI API when a client needs Salesforce to describe how data should be displayed, not just the data itself.
Metadata, Tooling, and custom Apex endpoints
Two APIs deal with the shape of an org rather than its records. Metadata API moves customizations such as objects, fields, and classes between orgs, and it is the engine behind sandbox to production deployments and many release pipelines. Tooling API works at a finer grain on development time artifacts, which is why the Developer Console and IDEs use it to query and modify code and configuration. Neither typically appears in a customer facing data integration, but both are central to how teams build and ship on the platform. When the standard data APIs do not cover a need, developers write custom endpoints. An Apex REST class exposes a custom HTTP endpoint under /services/apexrest with whatever logic the developer codes, and it runs with the calling user's permissions. Apex SOAP web services do the same over SOAP. These let an org act as both a data store and a small API server, wrapping complex business rules behind a single clean call. They are the escape hatch for cases where the generic CRUD surface is not enough, while still inheriting Salesforce security and sharing.
Limits, governance, and outbound callouts
Every inbound API call counts against the org's API request allocation. That allocation is measured per 24 hour rolling period and scales with the org's edition and the number of user licenses it holds, with paid editions starting from a large base and growing from there. Hitting the daily cap is disruptive and largely preventable, so mature teams watch consumption through the API Usage dashboard and the REST limits resource at /services/data/vXX.0/limits, then alert before they approach the ceiling. Using the API requires the API Enabled permission and a qualifying edition. Governance is not only about inbound traffic. Salesforce also consumes external APIs through Apex callouts and External Services, both authenticated with Named Credentials so endpoints and secrets live in configuration rather than code. The same discipline applies in both directions. Honor rate limits, retry transient failures with backoff, and design endpoints to be idempotent so a repeated call cannot double process a record. Integrations retry eventually, so an endpoint that is safe to call twice is a requirement, not a nicety.
Trust & references
Cross-checked against the following references.
- API Basics: Get to Know Salesforce APIs (Trailhead)Salesforce
- Pub/Sub API: Get StartedSalesforce
Straight from the source - Salesforce's reference material on Application Programming Interface (API).
- Introduction to Bulk API 2.0 and Bulk APISalesforce
- API Request Limits and AllocationsSalesforce
Hands-on resources to go deeper on Application Programming Interface (API).
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Which Salesforce API is best suited for moving large data volumes?
Q2. Which API would you use for real-time event-driven integration?
Q3. What do all Salesforce APIs consume against the org's limits?
Discussion
Loading discussion…