Salesforce API Integration: Which API to Use, Auth, Limits and Setup (2026)

Salesforce API types for integration: which one for which job

Every Salesforce API reads and writes the same objects. They differ in how many records they handle per call, whether they are synchronous, and who starts the conversation. Choose by the job, not by habit.

Two older options still appear in tutorials. The Streaming API’s PushTopic and generic events are marked legacy in Salesforce’s documentation; new event-driven work goes through Pub/Sub API.

Versions matter too. According to the REST API guide, as of October 2026 the current API version is 68.0 (Winter ’27). Versions 31.0 to 40.0 become unsupported from Summer ’27 and retired from Summer ’28, and calls to retired versions return 410 GONE. If your code pins an old version, budget time to move it.

Which API fits your integration?

Answer for one integration at a time: record counts, who calls whom, freshness, and how much logic one business action carries. The result is the API to start with; larger integrations usually add a second one later.

The API is half of the design. The other half is the pattern: request and reply, fire and forget, batch sync or data virtualization. Our Salesforce integration patterns guide covers when to use each one.

How data moves in and out of Salesforce

Most integrations combine three directions: an external system pushes records in, Salesforce tells the outside world what changed, and Salesforce calls an external API in the middle of a process.

Authentication in 2026: External Client Apps, OAuth flows and Named Credentials

Connected Apps vs External Client Apps

Every external client needs an app definition in Salesforce that holds its OAuth settings. For years that was a connected app. That has changed:

• Spring ’26: Salesforce’s REST API guide says creating connected apps is restricted. Existing connected apps keep working, but Salesforce recommends External Client Apps, and creating a new connected app requires Salesforce Support.
• Summer ’27: in its Winter ’27 architect highlights (October 2026), Salesforce says connected app support ends by Summer ’27 and advises starting the migration to External Client Apps now.

External Client Apps use a closed-by-default security posture and keep the developer’s app settings apart from the admin’s policies. For a new integration, create an External Client App. For existing ones, list every connected app in Setup, find its owner and the integrations behind it, and plan the move before the deadline rather than after the first failure.

Which OAuth flow to use

Whatever the flow, the token acts as a Salesforce user, and that user’s profile and permission sets decide what the integration can see and change. Use a dedicated integration user per integration, not an admin’s login.

Supported editions include a limited number of free Salesforce Integration user licenses for exactly this purpose, limited to API-only access. Our Salesforce integration user guide covers the license, permission sets and setup.

Outbound calls: Named Credentials and External Credentials

When Salesforce calls another API, don’t put URLs, tokens or passwords in Apex code or custom settings. A Named Credential holds the endpoint, and its External Credential holds the authentication settings (for example OAuth, JWT, AWS Signature v4 or custom headers). Apex then calls callout:My_Named_Credential/path, and Salesforce adds the credentials.

Callouts through a Named Credential also don’t need a separate Remote Site Setting. Permission sets grant access to each External Credential principal, so only the users and integration users you choose can make the callout.

How to build your first server-to-server integration, step by step

These steps cover the most common case: an external service (your app, ERP connector or middleware) reads and writes Salesforce records. Most of the risk sits in steps 1, 3 and 9, not in the code. For the Setup screens themselves, use Salesforce Help, because labels move between releases.

1. Write the contract firstWhich objects and fields, which direction, which system is the record of truth for each field, how fresh the data must be, and expected volumes per day. That decides the API: REST and Composite for record-level traffic, Bulk API 2.0 for volume, events for change notifications.
2. Work in a sandboxBuild and test against a sandbox or Developer Edition org, never production. Check your production edition has API access (Enterprise, Performance and Unlimited do; Professional needs the add-on).
3. Create the integration userA dedicated user with the Salesforce Integration license if available, plus a permission set that grants only the objects and fields in your contract. Turn on API Only access so nobody can log in to the UI with it.
4. Add an external ID fieldOn every object you write to, add a unique external ID field holding the other system’s key (for example ERP_Id__c). Upserts on it make retries safe and prevent duplicates.
5. Create an External Client AppEnable OAuth, select the scopes you need (start with API access), enable the client credentials flow and set your integration user as the run-as user. Store the consumer key and secret in your secrets manager, not in code or chat.
6. Get a token and make a first callRequest a token from your My Domain URL, then call the /limits resource. If that works, authentication, permissions and network are fine. The example below shows both, plus an upsert.
7. Write with upserts and CompositeUpsert by external ID, bundle related writes with Composite or sObject Collections, and move any job above roughly 2,000 records to Bulk API 2.0, as Salesforce’s limits guide suggests.
8. Subscribe to changes if data flows backEnable Change Data Capture for the objects the other system needs, subscribe through Pub/Sub API, and store the replay ID after each processed event.
9. Add error handling and monitoringRetries with backoff for retryable errors, a dead-letter queue for the rest, structured logs with record IDs, and an alert when API usage passes a threshold.
10. Test the ugly cases, then deployDuplicate keys, validation rule failures, locked records, expired tokens, a deleted record, and a full-volume load. Then recreate the app and user in production, and run a pilot before switching on all traffic.

# 1. Get an access token (client credentials flow, your My Domain URL)
curl -X POST https://YOUR-DOMAIN.my.salesforce.com/services/oauth2/token \
  -d grant_type=client_credentials \
  -d client_id=$CONSUMER_KEY \
  -d client_secret=$CONSUMER_SECRET

# 2. Check your limits (also a cheap smoke test)
curl https://YOUR-DOMAIN.my.salesforce.com/services/data/v68.0/limits \
  -H "Authorization: Bearer $ACCESS_TOKEN"

# 3. Upsert an account by an external ID field (201 = created, 200 = updated)
curl -X PATCH https://YOUR-DOMAIN.my.salesforce.com/services/data/v68.0/sobjects/Account/ERP_Id__c/C-10042 \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"Name": "Acme Inc.", "BillingCity": "Austin"}'

Use a recent API version consistently and change it on purpose, not by accident. A PATCH to the external ID URL returns 201 when it creates a record and 200 when it updates one; a 300 means the external ID matched more than one record, which is a data problem to fix, not to retry.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Salesforce API limits and how to stay under them

Limits are shared by every integration, managed package and tool in the org. One noisy integration can starve the others. These are the ones that matter most, according to Salesforce’s developer limits reference and API guides as of October 2026:

How to stay under them:

• Subscribe, don’t poll. A job that asks “anything new?” every minute burns 1,440 calls a day per object. Change Data Capture costs nothing until something changes.
• Batch everything. Use sObject Collections and Composite for small groups, Bulk API 2.0 above a few thousand records.
• Ask only for what you need. Select specific fields in SOQL, filter by SystemModstamp or LastModifiedDate for incremental syncs, and cache reference data such as picklists and record types.
• Watch usage in every response. REST API returns the Sforce-Limit-Info header (for example api-usage=10018/100000). Slow down your own jobs when usage passes a threshold you set, and alert a person before the org hits the wall.
• Check partner apps. Calls from installed managed packages count against the same allocation. If one package dominates usage, ask the vendor.

Paid production orgs can exceed the daily allocation for a while during spikes, up to a hard cap. Salesforce says not to rely on that; if you need more, buy more calls or licenses through your account team.

Error handling and retries

Retry only what can succeed on the second try. Retrying a validation error just burns API calls and fills logs.

Three habits make retries safe. Write with upserts on external IDs, so a repeated call updates instead of duplicating. For events, deduplicate on the event’s UUID (the EventUuid field, which Pub/Sub API delivers as the event id), and store the replay ID only after processing succeeds.

Finally, set allOrNone on Composite and Collections calls deliberately. true rolls back the whole set on one failure. false saves what it can and returns errors per record, which you must then handle one by one.

Pitfalls and how to fix them

Build it yourself, use an iPaaS, or both

Not every integration needs custom code. Native connectors and AppExchange (now AgentExchange) apps cover many common pairs. An iPaaS (integration platform as a service) such as MuleSoft, Workato or Boomi handles mapping, retries and monitoring for you.

They all call the same APIs underneath, so the limits and authentication rules above still apply. If MuleSoft is on the table, see our Salesforce MuleSoft integration guide; for the wider choice between native, iPaaS and custom, start with the Salesforce integration guide.

Direct API work pays off when the logic is specific to your business, when volumes make per-task pricing expensive, or when you need full control over errors, security and data residency. A typical build is a small service with a token cache, a mapping layer, a queue, idempotent writes, an event subscriber and dashboards.

Where an API project lands in these ranges depends mostly on how many objects, directions and error paths it has. The ranges and their drivers are from our API integration cost guide; if the work is mostly bulk data movement, the cost of data integration is the better reference.

Go-live checklist

Use this as the gate between sandbox and production. If auth, idempotency or monitoring boxes stay empty, fix those before a pilot rather than after.

FAQ

Where Gilzor fits

If the connected app deadline or a limit-hungry integration is what brought you here, that is the kind of work Gilzor takes on: we are a software development company with engineers in Poland and Cyprus, not a Salesforce reseller. We can choose the APIs and OAuth flows with you, migrate connected apps to External Client Apps, and build and support the integration service with idempotent writes, event subscriptions and monitoring. Scoping is explained on our Salesforce integration services page.