Application Programming Interface (API)
An Application Programming Interface (API) is a defined contract that lets one software system call another.
Definition
An Application Programming Interface (API) is a defined contract that lets one software system call another. In the Salesforce world, the word API usually refers to one of the platform's standard interfaces (REST API, SOAP API, Bulk API, Streaming API, Pub/Sub API, Metadata API, Tooling API, Connect REST API, GraphQL API, User Interface API) plus any custom Apex REST endpoints an org exposes. Each Salesforce API speaks a particular protocol (HTTP/JSON, SOAP/XML, WebSocket, gRPC), exposes a particular surface (CRUD on standard objects, bulk loads, change-data events), and has its own authentication, governor limits, and rate ceilings.
APIs are how Salesforce participates in the broader integration estate. Inbound calls from external systems (a mobile app, a partner portal, a data warehouse) hit one of the platform APIs to read or write data. Outbound calls from Apex or Flow hit external APIs through Named Credentials and HTTP Callouts. Platform Events and Streaming API push real-time changes to subscribers. Each integration is a choice of which API matches the use case: REST for simple synchronous CRUD, Bulk for high-volume loads, Pub/Sub or Streaming for change-data capture, Connect REST for chatter and feed actions, GraphQL for selective field retrieval.
The Salesforce API surface in practice
REST API, the most common entry point
The Salesforce REST API speaks HTTP and JSON, supports CRUD on every standard and custom object, and is the modern default for synchronous integrations. Endpoints follow the pattern /services/data/vNN.0/sobjects/{Type}/{Id}. Authentication is OAuth (with Named Credentials handling token refresh). Most modern integrations start here and only reach for other APIs when REST does not fit.
SOAP API for legacy compatibility
SOAP API speaks XML and uses a WSDL contract. It remains supported because thousands of legacy integrations still talk SOAP, but new development should default to REST. The functional surface is largely the same; the protocol is heavier.
Bulk API for high-volume data work
Bulk API (1.0 and 2.0) handles loads of tens or hundreds of millions of records asynchronously. Bulk 2.0 uses a simpler interface than 1.0 and is the recommended choice for new bulk integrations. Data Loader and many ETL tools use Bulk under the hood.
Streaming, Pub/Sub, and event delivery
Streaming API pushes change-data events and Platform Events to subscribers over CometD long-polling. Pub/Sub API is the newer gRPC-based replacement that supports both publishing and subscribing with better performance characteristics. Both are the right answer when an external system needs to know about Salesforce changes in near-real time.
Metadata, Tooling, and Connect REST APIs
Metadata API moves metadata (objects, fields, classes) between orgs. Tooling API is used by Developer Console and IDEs to query and modify development-time artifacts. Connect REST API exposes Chatter feeds and other social surfaces. Each fills a specific niche and rarely appears in customer integrations.
Apex REST and custom endpoints
Apex REST classes let developers expose custom HTTP endpoints with custom logic. The endpoint URL is /services/apexrest/path. Apex REST inherits the running user's permissions and applies whatever logic the developer writes. It is how Salesforce becomes both data store and API server for bespoke integration needs.
API limits and governance
Every Salesforce API call consumes API request limits. Daily limits scale with org edition and license count; per-transaction limits apply within Apex callouts. Bulk API has its own batch and chunk limits. Mature integrations track API consumption with the API Usage Last 7 Days dashboard and alert when approaching daily caps.
Outbound APIs and Named Credentials
Salesforce also consumes external APIs. Apex callouts and External Services call out to REST or SOAP endpoints, authenticated through Named Credentials so secrets stay out of metadata. The same governance principles (rate limits, retry logic, idempotency) apply to outbound APIs.
How to choose and consume the right Salesforce API
Picking the right API is most of the work. Once chosen, authentication, error handling, and governance follow the same patterns regardless of which API the integration uses.
- Identify the integration shape
Synchronous CRUD, high-volume async load, near-real-time event delivery, metadata movement, or chatter feed action. Each maps to a different Salesforce API.
- Pick the right API
REST for synchronous CRUD. Bulk 2.0 for high-volume loads. Pub/Sub for event delivery. Metadata for metadata. Apex REST for bespoke logic. SOAP only for legacy compatibility.
- Set up authentication
Register a Connected App for OAuth. Use JWT Bearer flow or Server-to-Server flow for backend integrations; use Authorization Code for user-facing apps.
- Build idempotent, retry-aware logic
Every integration retries eventually. Idempotent endpoints handle retries safely. Error handling distinguishes retriable (5xx, 429) from non-retriable (4xx) responses.
- Monitor consumption
Watch the API Usage Last 7 Days dashboard. Alert before hitting daily limits. Right-size the integration if consumption grows faster than headroom.
- Daily API limits scale with edition and license count. High-volume integrations can exhaust the quota; right-size with Bulk or Pub/Sub instead of REST loops.
- Pinning to too old an API version misses platform improvements; staying on the latest needs ongoing regression testing.
- Each API has its own auth, governor limits, and idiosyncrasies. Mixing them inside one integration adds complexity.
- Apex REST endpoints inherit the running user's permissions. A poorly-scoped endpoint can leak data the running user should not see.
Trust & references
Cross-checked against the following references.
- REST API Developer GuideSalesforce Developer Docs
- Bulk API 2.0 Developer GuideSalesforce Developer Docs
Straight from the source - Salesforce's reference material on Application Programming Interface (API).
- Salesforce Developer DocumentationSalesforce Developer Docs
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…