Salesforce exposes its data and functionality through multiple APIs — the mechanisms that allow external systems to read from, write to, and interact with your Salesforce org programmatically. Understanding which API to use for which use case, how authentication works, and what the basic request structure looks like is the foundation of any Salesforce integration project. This introduction covers the primary Salesforce APIs, when to use each, how OAuth authentication works, and how to make your first API call using Postman.
The best introduction is the one that makes the technical idea feel approachable.
A useful explanation should help the reader understand where the API fits in the platform.
That means the guide should focus on practical use rather than programming jargon.
For many organisations, the value is in being able to extend Salesforce without replacing it.
It should also show how APIs support integrations without losing control of the underlying system.
A good introduction should explain what the API is used for and why it matters in a CRM stack.
That makes it an important topic for teams that need flexibility.
Salesforce API is useful because it gives teams a way to connect Salesforce with other systems and build custom integrations. It is the technical path that allows data and actions to move between platforms when configuration alone is not enough.
The Salesforce API Landscape
Salesforce provides seven primary APIs, each designed for different use cases:
REST API
The most commonly used Salesforce API for modern integrations. REST API uses standard HTTP methods (GET to retrieve, POST to create, PATCH to update, DELETE to delete) and returns data in JSON format (XML also supported). REST API supports all standard and custom Salesforce objects and provides endpoints for querying via SOQL, searching via SOSL, retrieving record metadata, and managing file attachments.
Use REST API when: building a modern web or mobile application that reads and writes Salesforce data, integrating a third-party tool with Salesforce when volume is under 50,000 records per request, or building custom automation that creates and updates records based on external system events.
SOAP API
The older XML-based API, used by many enterprise integrations built before REST API was introduced. SOAP API provides the same core record operations as REST but uses XML envelopes rather than JSON. Most new integrations use REST API instead of SOAP, but SOAP remains the choice for platforms that have a SOAP client library and organisations with existing SOAP-based integration infrastructure.
Bulk API
Designed for processing large volumes of records — hundreds of thousands to millions of rows — efficiently. Bulk API uses an asynchronous job model: you create a job, upload batches of records in CSV or JSON format, and Salesforce processes them in parallel on its infrastructure. Jobs run asynchronously, so your integration polls for completion status rather than waiting for a synchronous response.
Use Bulk API when: loading or updating more than 10,000 records in a single operation, performing nightly data synchronisation from an ERP or data warehouse into Salesforce, running scheduled mass-update operations (updating account owner based on territory assignment changes), or extracting complete datasets for reporting.
Streaming API
Provides real-time event notifications from Salesforce to subscribing clients — instead of polling Salesforce every N minutes to check for changes, Streaming API pushes a notification to your client immediately when a change occurs. Streaming API has two event types:
- PushTopic: notifications triggered when records matching a SOQL query are created, updated, deleted, or undeleted. Example: a PushTopic for “notify when Opportunity Stage changes to Closed Won” triggers a notification to your billing system immediately when a deal closes, without polling.
- Change Data Capture (CDC): a more powerful alternative to PushTopics — CDC publishes every field-level change to subscribed objects as a stream event, including the old and new field values. CDC events are retained for 3 days, so subscribers that were offline can replay missed events on reconnection.
- Platform Events: custom events that any Salesforce process (Apex trigger, Flow, external API call) can publish, and any subscriber can receive — used for building loosely-coupled event-driven integrations between Salesforce and external systems.
Metadata API
Used for deploying and retrieving Salesforce configuration — custom objects, fields, page layouts, workflows, Apex code, Lightning components, and all other org metadata. Metadata API is the API behind Salesforce CLI, change sets, and deployment tools like Copado and Flosum. Not used for data operations (record CRUD) — used exclusively for org configuration management.
Tooling API
A developer-focused API for working with Apex code, Visualforce, Lightning Web Components, and test execution. The Salesforce developer tools (VS Code extension, Developer Console) use the Tooling API internally. For most integration developers, Tooling API is not directly needed — it is used by tooling platforms and IDE integrations.
Composite API
A REST API extension that allows bundling multiple sub-requests into a single HTTP call, reducing round-trip network latency. Three Composite API types:
- Composite: up to 25 sub-requests in one call, with the ability to use the output of one sub-request as input to subsequent sub-requests in the same call
- Batch: up to 25 independent sub-requests executed in a single call — each request is independent (no cross-referencing)
- SObject Tree: create a parent record and multiple related child records in a single API call
Authentication: OAuth 2.0
All Salesforce API calls require authentication — you must prove your identity before Salesforce returns or accepts data. Salesforce uses OAuth 2.0, the industry standard for API authentication. The OAuth flow produces an access token that is included as a Bearer token in the HTTP Authorization header of every subsequent API call.
Step 1: Create a Connected App
Before using OAuth, create a Connected App in Salesforce Setup (Setup → App Manager → New Connected App). Configure:
- App Name, Contact Email
- Enable OAuth Settings: check this
- Callback URL: the URL OAuth will redirect to after authentication (for server-side flows). For server-to-server integration, use any valid HTTPS URL.
- OAuth Scopes: select the permissions the integration needs — typically “Access and manage your data (api)” and “Perform requests on your behalf at any time (refresh_token)”
After saving, Salesforce provides a Consumer Key (client_id) and Consumer Secret (client_secret) — these identify your connected app in OAuth requests.
OAuth Flows
Username-Password Flow: the simplest flow, appropriate for server-to-server integrations where a service account credential is used. Send a POST request to the Salesforce token endpoint with your username, password, security token (if required), client_id, and client_secret. Receive an access token in response.
POST https://login.salesforce.com/services/oauth2/token Content-Type: application/x-www-form-urlencoded grant_type=password &client_id=YOUR_CONSUMER_KEY &client_secret=YOUR_CONSUMER_SECRET &username=YOUR_USERNAME &password=YOUR_PASSWORD+YOUR_SECURITY_TOKEN
Note: Salesforce is phasing out the Username-Password OAuth flow for new connected apps due to security concerns — the JWT Bearer Token flow is the recommended replacement for server-to-server integration.
JWT Bearer Token Flow: the recommended server-to-server authentication method. Uses a JSON Web Token signed with a certificate (rather than a username/password) to authenticate without human interaction. Requires: a certificate registered in the Connected App, the corresponding private key stored securely in your integration environment. The integration signs a JWT, sends it to the Salesforce token endpoint, and receives an access token.
Web Server (Authorization Code) Flow: used when a human user is authenticating — they are redirected to the Salesforce login page, log in, and Salesforce redirects back to your application with an authorization code that is exchanged for an access token. Used for user-facing applications that connect to Salesforce on behalf of a logged-in user.
Making Your First REST API Call
With an access token from the OAuth flow, make your first API request. All REST API endpoints follow this pattern:
https://YOUR_INSTANCE.salesforce.com/services/data/vXX.X/[endpoint]
Your instance URL and API version are found in Setup → Company Information (instance URL) and the API endpoint documentation (current version as of 2026 is v63.0).
Query Records with SOQL
GET https://na1.salesforce.com/services/data/v63.0/query?q=SELECT+Id,Name,Amount+FROM+Opportunity+WHERE+StageName='Closed+Won'+LIMIT+10 Authorization: Bearer YOUR_ACCESS_TOKEN
This returns a JSON response with the 10 most recent Closed Won opportunities, including their Id, Name, and Amount fields.
Create a Record
POST https://na1.salesforce.com/services/data/v63.0/sobjects/Contact
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json
{
"FirstName": "Jane",
"LastName": "Smith",
"Email": "jane.smith@example.com",
"AccountId": "001XXXXXXXXXXXXXXX"
}
A successful response returns HTTP 201 with the new record’s Id.
Update a Record
PATCH https://na1.salesforce.com/services/data/v63.0/sobjects/Contact/003XXXXXXXXXXXXXXX
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json
{
"Title": "Vice President of Sales"
}
PATCH updates only the fields included in the request body — other fields on the record are untouched. A successful response returns HTTP 204 with no body.
Testing with Postman
Salesforce maintains an official Postman workspace with pre-built API collections for all Salesforce APIs. Import the collection from the Salesforce Postman GitHub repository and configure environment variables (instance URL, access token) to start testing API calls without writing code.
The Postman collection includes: authentication flows (with pre-request scripts that automatically obtain and refresh access tokens), SOQL query requests, record CRUD operations, Bulk API job management, and Streaming API subscription examples.
API Limits
Salesforce enforces API call limits per org per 24-hour rolling window. Limits vary by edition:
- Enterprise Edition: 1,000 API calls per Salesforce licence per day (so a 50-user Enterprise org has 50,000 API calls/day)
- Unlimited Edition: 5,000 API calls per licence per day
Monitor API usage at Setup → System Overview → API Requests (Last 24 Hours). When building integrations that make high-volume API calls, use Bulk API (which uses separate Bulk API limits, not the standard API limit) or implement caching in your integration to reduce redundant calls.
The best API setup is the one that solves a real integration need. If the use case is vague, the technical work is harder to justify.
Conclusion
Salesforce’s API layer transforms the CRM from a standalone database into an integration hub — enabling external systems to read pipeline data, write activity records, trigger automations, and receive real-time change notifications. REST API and Bulk API cover the vast majority of integration use cases. OAuth 2.0 authentication via JWT Bearer Token is the secure, scalable approach for server-to-server integrations. Starting with a free Salesforce Developer Org (developer.salesforce.com — free signup) and the Salesforce Postman collection is the fastest path from zero API knowledge to making live API calls against a real Salesforce instance.
Sources
Salesforce, REST API Developer Guide (2026)
Salesforce, Bulk API 2.0 Developer Guide (2026)
Salesforce, OAuth Authorization Flows Documentation (2026)
Salesforce, Change Data Capture Developer Guide (2026)
Salesforce Postman, Official Salesforce API Collection (2026)