API
An API (Application Programming Interface) in Salesforce is the programmatic interface that external systems use to interact with the platform: read records, create records, update records, delete records, trigger automation, manage metadata, listen for events.
Definition
An API (Application Programming Interface) in Salesforce is the programmatic interface that external systems use to interact with the platform: read records, create records, update records, delete records, trigger automation, manage metadata, listen for events. Salesforce exposes several distinct APIs targeted at different use cases: REST API for standard CRUD operations and modern integrations, SOAP API for legacy enterprise integrations, Bulk API for high-volume data operations, Streaming API for real-time event subscriptions, Metadata API for configuration deployment, Tooling API for granular development operations, and several more specialized APIs.
The Setup area titled API typically refers to the configuration page where admins manage API access policies, view API consumption against limits, and download the WSDL files needed for SOAP API integrations. The page is essential for any org that does meaningful integration work: monitoring API consumption against the daily limit, managing user-level API access, and configuring the policy controls that protect the org from runaway integrations.
The Salesforce API surface area
REST API
REST API is the modern integration surface for most new Salesforce integrations. It exposes CRUD operations through HTTP endpoints with JSON request and response bodies. Operations include sObject CRUD (read or write specific records), SOQL queries, search via SOSL, Composite API (multiple operations in a single request), and many object-specific endpoints. REST API is the right choice for most integrations because of its simplicity, the universal HTTP tooling support, and the modern conventions. Authentication uses OAuth 2.0 with various flow options. Rate limits apply per org per 24 hours, with the limit scaled by edition and additional licenses.
SOAP API
SOAP API is the older enterprise integration surface that predates REST API on Salesforce. It exposes the same underlying CRUD and query operations through SOAP XML messages, with strongly typed WSDL-based contracts. SOAP API remains in heavy use in legacy enterprise integrations (older middleware platforms, traditional ESB connections) where the SOAP model fits naturally. New integrations rarely use SOAP API because REST API covers the same functionality with less complexity, but SOAP API is fully supported and not deprecated. The WSDL files for the Enterprise and Partner SOAP APIs are downloadable from the API Setup page.
Bulk API
Bulk API is the asynchronous high-volume integration surface for loading or extracting large datasets. Bulk operations support hundreds of thousands or millions of records per job, with the work processed in parallel batches by the Salesforce backend. Bulk API V2 is the modern version with simpler usage; the legacy Bulk API V1 remains supported. For data migration projects, nightly ETL jobs, and large-scale data updates, Bulk API is the right tool because it works within higher limits and processes data more efficiently than the row-by-row REST API. Customers using the Bulk API need to plan for the async job lifecycle: submit, poll for status, retrieve results.
Streaming and Pub/Sub APIs
Streaming API and the newer Pub/Sub API let external systems subscribe to Salesforce events in real time rather than polling for changes. Subscribers receive events as they occur: Platform Events fired from automation, Change Data Capture events on record changes, generic streaming channels for custom use cases. The legacy Streaming API uses CometD for the transport; the modern Pub/Sub API uses gRPC for higher throughput. Both APIs are the right tools for low-latency reactive integrations where polling would be expensive and laggy. The choice between them depends on the consumer's preferred transport and the volume requirements.
Metadata API and Tooling API
Metadata API and Tooling API handle org configuration rather than business data. Metadata API operates at the deploy-and-retrieve level for moving metadata between orgs (the foundation of Change Sets and Salesforce DX). Tooling API operates at the per-component level for development tools that need to read and write individual metadata pieces (the basis of the Developer Console and VS Code extensions). Both APIs work with the same underlying metadata concepts but at different granularity. Most customer DevOps relies primarily on Metadata API through SFDX or DevOps Center; Tooling API is more developer-facing.
Specialized APIs
Beyond the major APIs, Salesforce exposes specialized APIs for specific scenarios. Connect REST API for Chatter and Communities features. Reports API for executing reports programmatically. Analytics API for CRM Analytics integrations. Apex REST API for developer-defined custom endpoints. Each specialized API targets specific use cases, and the right choice depends on what the integration is trying to accomplish. The Salesforce Developer Documentation catalogs every API with its endpoints, authentication requirements, and rate limits. Selecting the right API for a given use case is one of the foundational integration architecture decisions.
API limits and monitoring
Salesforce enforces API limits per org per 24 hours: a base allocation that scales with edition (15,000 to 5,000,000 calls per day depending on edition and licensed users) plus any add-on API call packages. The limit applies across all APIs collectively, with specific APIs having their own sub-limits. Exceeding the daily limit causes new API calls to fail with a limit-exceeded error. The Company Information page and the System Overview page surface current API consumption against the limit. Mature integration programs monitor API usage continuously and alert on approaching the limit, well before it is hit. Bulk API can dramatically reduce API call consumption for high-volume scenarios because a single Bulk job can process many records as one logical operation.
The evolution of Salesforce APIs
Salesforce's API surface has evolved substantially since the early SOAP API in the mid-2000s. The introduction of REST API around 2010 modernized the standard integration path. Bulk API addressed the high-volume scenarios that REST and SOAP could not handle efficiently. Streaming API enabled real-time integrations through CometD-based subscriptions. Pub/Sub API replaced Streaming API for high-throughput event consumption. Metadata API and Tooling API matured alongside the Salesforce DX development model, supporting modern source-driven DevOps. Each evolution responded to specific customer needs and the broader industry shift in integration patterns. The trajectory continues with new APIs (Connect REST API for Communities, the Lightning Data Service for client-side data access, the various Industry Cloud APIs) being added regularly. Staying current on the API surface area is a meaningful professional development task for senior integration architects because the right API choice changes as the platform evolves and as the integration use case characteristics shift. What was the right answer in 2020 may not be the right answer in 2026, and the architect who has not been tracking the evolution may default to outdated patterns that produce suboptimal integrations.
Manage API access and consumption
Operating Salesforce APIs effectively spans configuration of access controls, monitoring of consumption, and integration design that respects limits. The workflow below covers the standard sequence for managing the org's API posture.
- Understand the org's API allocation
From Setup, open Company Information to see the current API call allocation: the base limit per 24 hours plus any add-on packages. Document the allocation in the team's runbook. Identify the integrations consuming API calls: Marketing Cloud sync, ERP integration, custom Apex callouts from external systems, MuleSoft flows, partner integrations. Estimate each integration's typical daily API consumption. The sum should be comfortably below the org's allocation; if it is approaching the limit, plan capacity additions or consumption optimizations.
- Configure user-level API access
From Setup, configure which user profiles have API Enabled (the permission allowing API access). Restrict API access to integration users and specific user roles that need it; general users typically should not have API access. For integration users, use Connected Apps with OAuth scopes that match exactly what the integration needs (no over-scoping). Configure IP restrictions on integration users where appropriate, limiting API access to known integration source IPs.
- Monitor API consumption continuously
Set up monitoring on API consumption against the limit. The Setup page System Overview shows current consumption; for continuous monitoring, integrate with the org's standard observability platform (Splunk, Datadog) through Event Monitoring or the API limit API. Configure alerts that fire when daily consumption exceeds defined thresholds (60 percent of allocation triggers attention, 80 percent triggers escalation). Track trends over time to identify which integrations are growing and may need optimization or additional capacity.
- Design integrations to respect API limits
For new integrations, design with API efficiency in mind: use Bulk API for high-volume operations, batch operations through Composite API, cache data on the integration side to reduce repeated reads, use Change Data Capture or Platform Events instead of polling. Review existing integrations periodically for chatty patterns that consume API calls without delivering proportionate value. Refactoring inefficient integrations is often more cost-effective than purchasing additional API capacity.
- Exceeding the daily API limit causes new calls to fail. The fix is purchasing add-on capacity or waiting for the 24-hour reset.
- Bulk API calls are counted differently from REST or SOAP. A Bulk job processing 100,000 records is one API call, not 100,000.
- Different APIs have different rate limits. Streaming API has connection limits separate from the daily call limit.
- Integration user-level IP restrictions can lock out integrations if not configured carefully. Test thoroughly before enforcing.
- Connected App OAuth scopes are minimal-permission by design. Over-scoping creates security risk; under-scoping breaks the integration.
Trust & references
Cross-checked against the following references.
- Salesforce API DocumentationSalesforce Developer Docs
Straight from the source - Salesforce's reference material on API.
- REST API Developer GuideSalesforce Developer Docs
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. What skill set is typically needed to work with API?
Q2. Where would a developer typically work with API?
Q3. What is required before deploying API-related code to production?
Discussion
Loading discussion…