What is the Connected App OAuth flow for Salesforce integrations and which grant type should you use?

Salesforce integrations authenticate via Connected Apps using OAuth 2.0. The grant type depends on the integration's access pattern. The JWT Bearer Token flow (server-to-server, no user interaction) is the recommended approach for system integrations running as a service account — it uses a pre-approved certificate rather than a user login, making it suitable for background processes, nightly ETL jobs, and middleware that runs without human initiation. The Username-Password flow is simpler to implement but less secure (credentials are included in the token request) and is not recommended for new integrations. The OAuth Web Server flow (authorisation code) is appropriate for user-facing integrations where individual users authorise the connected app to act on their behalf.

Salesforce Integration Patterns: REST, Bulk API, Platform Events — Which One When

Q: What is the difference between Salesforce REST API and Bulk API?

The Salesforce REST API processes records individually or in small batches — each request handles up to 200 records (via composite requests) and returns a synchronous response. It is designed for real-time, transactional integrations where you need an immediate response: a CRM system looking up a customer record, a CPQ tool creating an Opportunity when a quote is finalised, or a service portal creating a Case when a customer submits a form. The Bulk API processes records asynchronously in large batches — it is designed for data volume operations: loading 500,000 records from a data warehouse, syncing daily exports from an ERP, migrating data between orgs. The REST API is right for latency-sensitive operations; the Bulk API is right for volume-sensitive operations.

Q: What are Platform Events in Salesforce and when should you use them?

Platform Events are Salesforce's native event-driven messaging system. Rather than polling Salesforce for changes (which consumes API calls and creates latency), a system can subscribe to Platform Events and receive notifications in near-real-time when specific events occur. Use Platform Events when you need to: decouple Salesforce from downstream systems (the event fires and Salesforce does not need to know what happens next); handle asynchronous processing within Salesforce (fire an event from a record update and process the response via a subscriber flow or Apex trigger); or integrate multiple systems without creating tight coupling. Platform Events are subject to daily allocation limits based on your org edition.

Q: How do you avoid hitting Salesforce API governor limits in an integration?

Salesforce API limits are based on your org edition — Enterprise Edition provides 1,000 API calls per Salesforce licence per day. The most common ways to manage limits: use the Bulk API for volume operations instead of making thousands of individual REST API calls; implement caching in your middleware for frequently read data that does not change often; batch your read requests using SOQL with selective filters rather than pulling all records and filtering in your middleware; monitor daily API usage in Setup > System Overview and set alerts before hitting limits; and design your integration to run batch operations during off-peak hours rather than continuously throughout the day.

Q: What is the role of middleware in Salesforce integration architecture?

Middleware (MuleSoft, Boomi, Jitterbit, Workato, or similar) sits between Salesforce and other systems, handling data transformation, protocol translation, routing, error handling, and retry logic. Not every Salesforce integration requires middleware — direct integrations via Apex callouts or external services can handle simpler scenarios. Middleware becomes necessary when: you are integrating more than two systems and need a central orchestration layer; you need sophisticated data transformation that would require complex Apex; you need guaranteed delivery and retry for integration failures; or your integration team has middleware expertise that makes it faster to build and maintain integrations in that layer than in Salesforce Apex.

Every Salesforce integration choice is a trade-off between latency, volume, reliability, and API consumption. Choose REST for a bulk data load and you will hit your daily API limit before noon. Choose Platform Events for a synchronous transaction that needs a response code and you will spend weeks debugging edge cases. The Salesforce integration architecture decision — which pattern, which API, which middleware — determines not just whether the integration works at launch, but whether it holds up under production load, stays within governor limits, and remains maintainable as data volumes grow and requirements change.

The Five Core Integration Patterns in Salesforce

Pattern	Best For	Direction	Timing
REST API	Real-time transactional operations, record CRUD	Inbound + outbound	Synchronous
Bulk API 2.0	Large data volume loads and exports	Inbound + outbound	Asynchronous
Platform Events	Event-driven notifications, decoupled integrations	Outbound from Salesforce	Near-real-time async
Outbound Messaging	SOAP-based notifications on record change	Outbound from Salesforce	Asynchronous
Apex Callouts	Custom outbound HTTP calls triggered by automation	Outbound from Salesforce	Synchronous or async

REST API: Right for Transactional Real-Time Integrations

The Salesforce REST API is the default choice for integrations that need to create, read, update, or delete individual records or small batches in real time. The REST API is fast, widely understood, and returns a synchronous response — making it appropriate when the calling system needs to know immediately whether the operation succeeded.

The REST API's key constraints: it consumes one API call per request (or one per 25 records using composite requests), it processes each request synchronously within Salesforce's governor limits, and it has a request payload limit of 12 MB. For integrations that create or update hundreds of records per hour, the API call consumption is manageable. For integrations that need to process thousands of records in a short window, the REST API is the wrong tool.

Common REST API use cases:

Customer portal creating a Case when a support ticket is submitted
CPQ tool creating an Opportunity and related Products when a quote is signed
Marketing automation syncing a Contact's email open event within minutes of the action
ERP updating an Account's billing address when a customer updates it in the ERP

Bulk API 2.0: Right for Volume Operations

The Bulk API 2.0 is designed for operations that involve thousands to millions of records. Instead of individual HTTP calls per record, the Bulk API accepts CSV or JSON files that are processed asynchronously in batches by Salesforce's bulk processing infrastructure. The calling system submits the job, polls for completion (or receives a callback), and then retrieves the results.

The trade-off: asynchronous processing means there is no immediate response. A bulk insert job might take minutes to hours depending on volume and current org load. This is acceptable for nightly ETL jobs, data migrations, and large historical imports where latency is not a concern. It is not acceptable for customer-facing operations where the user expects immediate feedback.

The Bulk API does not consume your daily API call limit in the same way the REST API does — bulk jobs are governed separately and can process significantly more records per day than individual REST calls would allow.

Platform Events: Right for Event-Driven Decoupling

Platform Events are Salesforce's native publish-subscribe messaging system. Any system (internal or external) can publish a Platform Event; any subscriber (a Flow, an Apex trigger, or an external system via CometD streaming) receives the event near-real-time and processes it independently.

The key advantage of Platform Events is decoupling. When Salesforce publishes an event because a Case was closed, it does not need to know or care what happens next. The downstream systems — a billing system that needs to generate an invoice, a customer survey platform that needs to send a CSAT survey, an ERP that needs to close a service ticket — each subscribe to the event and handle it independently. If one downstream system is temporarily unavailable, it does not affect the others.

Need help designing your Salesforce integration architecture?

CloudEzee's consulting team has designed integrations for ERP-Salesforce, marketing automation, payments, and data warehouse use cases across financial services, healthcare, and technology sectors.

Book Free Consultation →

Apex Callouts: Right for Custom Outbound Calls

When Salesforce needs to call an external system synchronously as part of a record save or automation, Apex callouts are the tool. A trigger fires when a record is updated, the Apex code makes an HTTP callout to an external REST or SOAP endpoint, processes the response, and optionally updates the Salesforce record based on the result.

The critical constraint: Apex callouts within synchronous transactions have a 10-second timeout limit and cannot be made from before-save triggers. Callouts that might be slow or unreliable should be executed from @future methods or Queueable Apex to avoid blocking the user's record save. Using synchronous callouts in triggers is one of the most common integration anti-patterns in Salesforce — it creates unpredictable save times and governor limit interactions that are difficult to reproduce and debug.

Choosing the Right Pattern: A Decision Framework

Need a real-time response? → REST API
Processing more than 10,000 records at a time? → Bulk API 2.0
Need Salesforce to notify an external system when something changes? → Platform Events or Outbound Messaging
Need to call an external API as part of Salesforce automation? → Apex Callout (async if latency is a risk)
Multiple downstream systems need the same event? → Platform Events (fan-out to multiple subscribers)

Frequently Asked Questions

What is the difference between Salesforce REST API and Bulk API?

The REST API processes records individually or in small batches synchronously — right for real-time transactional operations. The Bulk API processes records asynchronously in large batches — right for volume operations like ETL loads, data migrations, and nightly syncs. REST API is for latency-sensitive operations; Bulk API is for volume-sensitive operations.

What are Platform Events in Salesforce and when should you use them?

Platform Events are Salesforce's native publish-subscribe messaging system. Use them when you need to decouple Salesforce from downstream systems, handle asynchronous processing without a synchronous response requirement, or fan-out a single Salesforce event to multiple downstream subscribers. They avoid the polling overhead of periodic API calls.

What is the Connected App OAuth flow for Salesforce integrations?

The JWT Bearer Token flow is recommended for system-to-system integrations — it uses a pre-approved certificate rather than user credentials, making it suitable for background processes. The Username-Password flow is simpler but less secure. The Web Server flow is appropriate for user-facing integrations where individual users authorise the app.

How do you avoid hitting Salesforce API governor limits in an integration?

Use Bulk API for volume operations instead of individual REST calls; cache frequently read data in middleware; batch read requests with selective SOQL; monitor daily API usage and set alerts; run batch operations during off-peak hours. Enterprise Edition provides 1,000 API calls per Salesforce licence per day.

What is the role of middleware in Salesforce integration architecture?

Middleware handles data transformation, protocol translation, routing, error handling, and retry logic between Salesforce and other systems. It becomes necessary when integrating more than two systems, needing sophisticated data transformation, requiring guaranteed delivery with retry, or when your team has stronger middleware expertise than Apex.