Salesforce API Guide: Types of Salesforce APIs, Limits, and How to Choose

Every Salesforce integration starts with the same question: which Salesforce API should we use? Pick the wrong one, and you burn through your daily request allocation, wait hours for a data load that could run in minutes, or build on a version Salesforce is about to retire.

Salesforce now ships more than a dozen APIs. REST API and SOAP API handle most record operations, Bulk API 2.0 moves large data volumes, Pub/Sub API streams events, GraphQL API trims payloads, and the newest additions connect AI agents to your org.

This guide covers every main type of Salesforce API, what each one is built for, the request limits that shape your architecture, how authentication and API versioning work in 2026, and how to choose between them. Every number here comes from Salesforce documentation and is linked, so you can verify it or send it to your architect.

Key Takeaways

• Salesforce APIs fall into 6 groups: data APIs, event APIs, metadata and tooling APIs, UI APIs, analytics and data APIs, and AI APIs.
• Salesforce REST API suits most integrations, Salesforce SOAP API fits ERP and finance systems that need a WSDL contract, and Bulk API 2.0 handles large data volumes.
• Enterprise Edition orgs get 100,000 API calls per 24 hours plus 1,000 calls per license, so limits shape design decisions from day one.
• Salesforce retired API versions 21.0 through 30.0 in Summer '25, and the SOAP login() call in versions 31.0 through 64.0 retires in Summer '27.
• New legacy connected apps can no longer be created as of Spring '26, and External Client Apps replace them.
• Agent API and Salesforce-hosted MCP servers give AI agents access to org data under the same permission model as any other integration.

What Is a Salesforce API?

A Salesforce API is an interface that lets an external system read from or write to a Salesforce org programmatically, without a person clicking through the user interface. An ERP creates an order, a support portal opens a case, a data warehouse pulls 20 million records overnight: each of those moves through a Salesforce API.

All Salesforce APIs share one security model. Every API call runs as an authenticated user, and that user's profile, permission sets, field-level security, and sharing rules apply exactly as they do in the UI. A Salesforce API never grants access that the user does not already have.

Salesforce APIs also share one request allocation, so the API you choose changes how much of that allocation a workload consumes. That makes API selection an architecture decision with real cost consequences. If you are still deciding how the whole integration should be shaped, our comprehensive guide to Salesforce integration covers patterns, tools, and the delivery process around these APIs.

Types of Salesforce APIs: The Complete List

Salesforce groups its integration APIs by what they act on: records, events, metadata, the user interface, analytics data, or AI agents. Salesforce maintains its own overview of which API to use, and the table below expands it with protocol, use case, and limit impact.

Core Salesforce Data APIs: REST, SOAP, Bulk, GraphQL, and Composite

These 5 APIs cover record operations. Most Salesforce integration work starts here.

Salesforce REST API

Salesforce REST API is the default choice for new integrations. It exposes records, SOQL queries, and describe calls through HTTP endpoints, returns JSON by default, and works with any language that can send an HTTP request. Salesforce documents it in the REST API Developer Guide.

Use Salesforce REST API for web and mobile applications, service-to-service integrations, middleware connectors, and any workload that moves small to moderate volumes of records in real time.

One detail many teams miss: REST API includes a /limits resource that reports your remaining API allocation for the current 24-hour window. Wire it into monitoring on day one, before the first outage teaches you to.

Salesforce SOAP API

Salesforce SOAP API was the original Salesforce API and remains fully supported. It uses XML messaging with a WSDL contract, which is what many ERP, finance, and middleware platforms expect. Salesforce provides 2 WSDL types, documented in the SOAP API Developer Guide: the Enterprise WSDL, which is strongly typed and tied to a single org's schema, and the Partner WSDL, which is loosely typed and works across orgs.

Choose SOAP API when the system on the other side generates client code from a WSDL, or when finance and audit teams require strict typing. Our ERP integration team still meets this requirement regularly.

One change to plan for: Salesforce is retiring the SOAP login() call in API versions 31.0 through 64.0 in Summer '27, and it is already disabled by default in orgs created from Winter '26 onward. Integrations that authenticate with a username and password through login() need to move to OAuth 2.0.

Salesforce REST API vs SOAP API

The practical difference between Salesforce REST API and SOAP API is the contract: REST API uses JSON over HTTP with documented endpoints, while SOAP API uses XML with a formal WSDL. Both share the same limits, the same security model, and nearly the same functional coverage.

The decision comes down to what the system on the other side expects.

Bulk API 2.0

Bulk API 2.0 processes large data volumes asynchronously. You upload CSV data to a job, Salesforce creates the batches for you, processes them in the background, and reports results when the job completes. Salesforce recommends Bulk API 2.0 once you are working with roughly 2,000 records or more, and documents it in the Bulk API 2.0 and Bulk API Developer Guide.

The documented Bulk API allocations are worth knowing before you design a nightly sync.

Records also carry structural limits: 131,072 characters per field, 5,000 fields per record, and 400,000 characters per record.

GraphQL API

Salesforce GraphQL API lets a client request exactly the fields it needs in a single call, which reduces payload size and round trips on data-heavy screens. Salesforce documents it in the GraphQL API guide.

GraphQL API runs on Connect REST API infrastructure and uses the same Connect API limits, returning a 503 error when those limits are exceeded. In Summer '26, GraphQL mutations gained field references, so you can chain dependent records in one request with the @{ref.Record.FieldName.value} syntax, as described in the Summer '26 developer release guide.

Composite API

Composite resources let you send a series of REST calls in 1 HTTP request that counts as 1 call against your API allocation. This is the cheapest way to reduce API consumption without touching your data model.

• Composite: up to 25 subrequests per call, of which up to 5 can be sObject Collections or query operations. Later subrequests can reference results from earlier ones.
• Composite graphs: up to 75 graphs per payload and 500 nodes, with at most 15 different node types. Processing halts after 14 graph failures.
• sObject Collections and sObject Tree: create, update, or delete multiple records of the same type in one request. When an integration runs close to its daily allocation, auditing chatty call patterns and moving them into composite requests usually buys more headroom than raising the limit.

Event APIs: Pub/Sub API and Streaming API

Event-driven integrations react to changes as they happen, and they do not consume the platform API allocation.

Pub/Sub API is the current option for event work. It uses gRPC with Apache Avro binary encoding, supports publishing and subscribing through one interface, and gives the client flow control: your subscriber requests the number of events it wants, so it absorbs load on its own terms. Pub/Sub API also returns a publish confirmation, which matters when events carry financial or operational data.

Streaming API is the older CometD-based interface. It still supports platform events and change data capture, but Salesforce documents PushTopic events and generic events as legacy. New event integrations belong on Pub/Sub API, and existing PushTopic subscriptions deserve a place on your migration list.

Both APIs pair well with Change Data Capture when an external system needs to stay synchronized with Salesforce record changes without scheduled queries. If your sync target is a Postgres database, our guide to Heroku and Salesforce covers another route.

Metadata and Tooling APIs

Metadata API and Tooling API work on the org itself instead of its records.

Metadata API moves metadata between Salesforce orgs during development: objects, fields, layouts, permission sets, flows, and everything else you deploy from sandbox to production. It is SOAP-based, works asynchronously for deployments, and sits behind most CI/CD pipelines in the Salesforce ecosystem.

Tooling API is built for development tools. It gives fine-grained, query-based access to Apex classes, triggers, debug logs, code coverage, and checkpoints, in both REST and SOAP flavors. Code quality dashboards, deployment checkers, and org analysis tools run on it.

Salesforce also released a Metadata API Context MCP Server in beta in Summer '26, which exposes metadata context to AI clients through 5 granular tools.

UI APIs: User Interface API and Connect REST API

User Interface API returns records together with their layout, theme, and picklist metadata, so a custom mobile or web app can render a Salesforce-accurate UI without hard-coding field lists. Because layouts and field-level security travel with the data, your custom UI stays correct when admins change the org. Summer '26 added a GET /ui-api/session/csrf resource for CSRF token protection.

Connect REST API covers the collaboration and digital experience layer: Experience Cloud sites, Salesforce CMS content, Chatter feeds, groups, notifications, and B2B Commerce. It is also the infrastructure under GraphQL API. As of Summer '26, Connect REST API moved from an hourly limit to the per-org, per-24-hour Salesforce Platform API limit, which makes capacity planning simpler for portal-heavy orgs.

Apex REST API and Apex SOAP API

Sometimes no standard endpoint fits the job. Apex REST and Apex SOAP let you expose your own Apex classes as web services, so an external system calls one endpoint that runs your validation, orchestration, and DML in a single transaction.

Custom endpoints make sense when an integration would otherwise need 5 or 6 standard calls to complete one business action, or when business logic belongs inside Salesforce. Keep them versioned and documented: custom endpoints are code, and they need the same lifecycle discipline as the rest of your org. This is usually where our Salesforce application development team gets involved.

Analytics and Data APIs

CRM Analytics REST API gives programmatic access to datasets, lenses, and dashboards: query data, load external data into datasets, and manage assets from outside the platform. Salesforce also publishes a Tableau Next REST API, so confirm which analytics product your org runs before you build.

Data 360 APIs cover the platform Salesforce previously called Data Cloud, renamed Data 360 on October 14, 2025. The main interfaces are the Ingestion API for streaming or bulk-loading external data, the Query API for running SQL against unified data, and profile and activation endpoints for retrieving and acting on unified profiles. These run on their own allocations, separate from the core platform API limit, which is one reason high-volume data workloads increasingly land there.

AI-Era APIs: Agent API and Salesforce-Hosted MCP Servers

Two newer Salesforce APIs matter if AI is on your roadmap.

Agent API exposes Agentforce agents over REST, so any system that can call an HTTP endpoint can start a session, send messages, and stream responses. Salesforce documents 4 main uses: embedding agents in websites, running headless agents for automation without a UI, connecting agents to external platforms, and letting agents invoke other agents. Our article on how Agentforce changes customer service covers the service side of this.

Salesforce Hosted MCP Servers became generally available on April 29, 2026 for Enterprise Edition orgs and above. An MCP server is a Salesforce-managed endpoint that exposes org data, flows, Apex actions, and queries to any AI client that speaks the Model Context Protocol, such as an assistant in Slack or a desktop AI client. Authorization uses OAuth with PKCE, and the authenticated user's CRUD permissions, field-level security, and sharing rules still apply, with every transaction auditable. Salesforce documents the setup in its hosted MCP servers guide.

The practical point: AI clients reach your org through the same permission model as any other integration, so the governance work you already did on API access carries over.

Planning a Salesforce integration and not sure which API fits?

Our team scopes integrations, maps data flows, and builds them end to end.

Explore Salesforce Integration Services

Salesforce API Limits You Need to Plan For

Salesforce API limits decide more architecture than most teams expect. The figures below come from the Salesforce API request limits and allocations documentation.

Total API requests per 24 hours by edition

REST API, SOAP API, Bulk API, Bulk API 2.0, and most Connect REST APIs count toward this allocation. Pub/Sub API and Streaming API do not.

Concurrency and timeouts

• 25 concurrent requests lasting 20 seconds or longer in production orgs and sandboxes.
• 5 concurrent long-running requests in Developer Edition and trial orgs.
• A 10-minute timeout for REST and SOAP calls, except query calls. How to monitor Salesforce API usage

Salesforce documents several monitoring options in its API limits and monitoring guidance:

• Query the /services/data/vXX.0/limits resource for your remaining allocation.
• Read the Sforce-Limit-Info response header, which reports current usage and the daily limit on REST and SOAP responses.
• Check daily usage in Setup on the Company Information and System Overview pages.
• Configure API Usage Notifications to email admins at thresholds such as 50%, 80%, and 90%.
• Give each integration its own user with the Salesforce Integration license, and populate the Sforce-Call-Options header with a client name. That last point is the one we recommend most often. When an org hits its limit at 3 p.m. and every call comes from one shared account named "API User," finding the source takes days.

Salesforce API Authentication and Access Control

Every Salesforce API call needs an access token, and how you obtain that token has changed.

OAuth 2.0 flows. Server-to-server integrations typically use the JWT bearer flow or the client credentials flow, both of which avoid storing a user password. Interactive applications use the web server flow. Salesforce covers these in its authorization documentation.

External Client Apps replace connected apps. As of Spring '26, new legacy connected apps can no longer be created. External Client Apps are the successor, with improved security and second-generation packaging support. Existing connected apps keep working and can still be installed through packages, and Salesforce has said an End-of-Support date will be announced, so new builds should start on External Client Apps. Salesforce provides a migration tool for the move and compares the two models in its feature comparison.

API access control. Admins can limit API access to allowlisted apps, block untrusted ones, and restrict external users from API access. A related security update from December 2025 stops users with the "Use Any API Client" permission from self-authorizing uninstalled connected apps, with a separate "Approve Uninstalled Connected Apps" permission for trusted admins.

Least privilege still applies. An integration user should see only the objects and fields its job requires. We have audited orgs where a single integration user had Modify All Data because it was faster during the pilot, and nobody revisited it for 3 years.

Salesforce API Versions and Retirements: What Changes and When

Salesforce publishes a new API version with each of its 3 annual releases. Summer '26 is API version 67.0, and Winter '27 documentation is published as version 68.0. Older versions keep working for years, then retire on an announced schedule.

Two habits keep this manageable. First, keep an inventory of every integration, its API version, and its owner. Salesforce suggests using Login History and the API Total Usage event log to find integrations still calling retiring endpoints. Second, pin an explicit version in your endpoints and put an annual review in the calendar, so a retirement never arrives as a surprise 410.

One client asked us to modernize an org where automations and API versions had drifted for years. Migrating legacy automations to Flows and upgrading API versions took planning, and it removed a class of failures that had been appearing at random.

How to Choose the Right Salesforce API

Start from the job you need done. This table maps common scenarios to the Salesforce API we would reach for first.

Three questions settle most of what is left:

1. How much data moves, and how often? Anything above a few thousand records per run belongs in Bulk API 2.0.
2. Does the process need to be real time? If yes, events beat polling, and polling every minute is the fastest way to exhaust an allocation.
3. Who owns the system on the other side? If a vendor's platform dictates the contract, the decision is already made for you.

When several systems and teams are involved, an integration platform can be worth the overhead. Our MuleSoft Salesforce integration guide covers when API-led connectivity pays off, and our MuleSoft consulting team works on those programs.

What We See in Real Salesforce API Projects

A few patterns show up repeatedly across the integrations our team has delivered.

Multiple ingestion paths beat one perfect path. For Purlos, an education technology platform, we built 5 ways to get data into Salesforce: REST API, SFTP, HubSpot, AWS, and direct upload through Experience Cloud. Their customers had very different levels of technical maturity, and forcing everyone onto one method would have blocked half of them.

Real-time messaging needs its own architecture. For Riptide, we built live chat and a generative AI agent that run inside Service Cloud and Experience Cloud, delivered as a managed package. High-volume, low-latency messaging has different requirements from record sync, and treating them the same leads to timeouts.

Middleware is not always the answer. A UK humanitarian nonprofit was paying for a middleware tool to connect Salesforce to its events platform. We rebuilt that integration directly and removed the recurring cost.

Two-way ERP sync needs clear data ownership. On a Salesforce and Microsoft Dynamics integration, the API calls were the easy part. The real work was agreeing which system owns each field, and what happens when both change the same record.

Time-sensitive integrations need retry logic. For a biopharmaceutical client coordinating therapy logistics, real-time REST integrations with external booking and logistics systems had to stay aligned inside a 60-hour window. Error handling and retries mattered as much as the happy path.

More examples live in our case studies, including accounting, payment, and ecommerce integrations.

Get your integration architecture reviewed before you build

We map data flows, pick the right APIs, and plan for limits, security, and versioning.

Book a Consultation

Salesforce API Best Practices

• Pin an API version and review it annually. Forgotten endpoints are how teams discover retirements the hard way.
• Use composite requests for related operations. 25 subrequests for the cost of 1 call is the easiest saving available.
• Move bulk work to Bulk API 2.0. Looping single-record REST calls is the most common cause of limit exhaustion we see.
• Prefer events over polling. Pub/Sub API subscriptions stay outside the platform API allocation.
• Give every integration its own user and client name. Attribution makes troubleshooting and access reviews possible.
• Handle errors and retries explicitly. Build for row-level failures, timeouts, and duplicate protection alongside the happy path.
• Monitor before you need to. The /limits resource, usage notifications, and the Sforce-Limit-Info header cost nothing to set up.
• Apply least privilege to integration users. Start from minimum object and field access, then add only what breaks.

Explore More Salesforce Integration Resources

• Salesforce Integration Services: how MagicFuse plans and delivers integrations.
• A Comprehensive Guide to Salesforce Integration: integration types, patterns, and a step-by-step process.
• MuleSoft Salesforce Integration Guide: when an integration platform earns its place.
• MuleSoft Development and Consulting Services: API-led connectivity with MuleSoft.
• Heroku and Salesforce: data sync options beyond the core APIs.
• Salesforce ERP Integration Services: ERP-specific integration work.
• Salesforce Integrations for Customer Support: service-side integrations.
• Salesforce Application Development: custom endpoints, Apex, and managed packages.