When to Use Salesforce Bulk API 2.0 from MuleSoft

When a MuleSoft integration needs to move a large number of Salesforce records, the first design question should not be:

How many REST calls can I run in parallel?

It should be:

Does this workload belong on a bulk interface?

Salesforce Bulk API 2.0 provides asynchronous operations for large datasets and can be a much better fit than issuing one network request per record.

Record-Oriented REST vs Bulk Processing

For a small interactive operation, a normal REST request is natural:

MuleSoft → Salesforce REST API → immediate response

For hundreds of thousands of records, repeating that pattern can create unnecessary API calls, latency, throttling, and retry complexity.

Bulk processing changes the model:

MuleSoft
   ↓
Create Bulk API job
   ↓
Provide dataset
   ↓
Salesforce processes asynchronously
   ↓
Check completion
   ↓
Retrieve results

The client manages a job rather than one synchronous request per business record.

Bulk Ingestion

Bulk API 2.0 supports large data ingestion operations such as insert, update, upsert, and other supported bulk operations.

A generalized flow is:

POST /jobs/ingest
       ↓
Receive job ID
       ↓
Upload CSV data
       ↓
Mark upload complete
       ↓
Salesforce processes job
       ↓
Read job status/results

The exact API version and operation should follow the current Salesforce Bulk API documentation.

Bulk Query

Bulk API 2.0 can also execute large SOQL queries asynchronously.

Conceptually:

Create query job
      ↓
Salesforce executes SOQL
      ↓
Poll/observe status
      ↓
JobComplete
      ↓
Download result pages

This is useful when a synchronous query would return a large dataset or when extraction is naturally part of a background integration process.

When Bulk API Is a Strong Candidate

Consider Bulk API 2.0 when:

• the operation involves a large number of records;
• immediate per-record response is unnecessary;
• processing can be asynchronous;
• the target operation maps naturally to bulk insert/update/upsert/query behavior;
• you want to reduce record-by-record HTTP overhead.

For example:

Nightly synchronization of 400,000 customer records

is a much stronger bulk candidate than:

User saves one customer and needs an immediate confirmation

Do Not Choose Bulk Only by a Magic Record Count

There is no single threshold that makes every integration switch from REST to Bulk API.

Consider:

record count
payload size
frequency
latency requirement
API limits
failure behavior
network overhead
target processing model

A scheduled job of 10,000 records may benefit from bulk behavior, while another integration with a few thousand highly dependent operations may require a different design.

Upsert Is Especially Useful for Synchronization

For integrations where a source system owns a stable identifier, Bulk API upsert can help make synchronization safer.

Conceptually:

sourceCustomerId → Salesforce External ID

Then the operation becomes:

match found     → update
match not found → insert

This is often easier to retry safely than maintaining separate insert/update decision logic in MuleSoft.

Bulk Does Not Remove Failure Handling

A job can complete with records that did not process successfully.

Your MuleSoft flow should treat these as distinct concepts:

job completed
≠
every record succeeded

The integration should retrieve and reconcile the appropriate job results and decide how failed records are recovered.

A recovery strategy might retain only stable source identifiers and fetch the current data again during retry rather than storing every original payload.

Avoid Polling Too Aggressively

Bulk operations are asynchronous. Checking job status in a tight loop adds calls without making Salesforce finish faster.

Use a deliberate polling interval or an event-driven completion capability where supported by the API and appropriate for your architecture.

The integration should also have a timeout or operational escalation path for jobs that remain incomplete longer than expected.

Bulk API and Mule Batch Are Different Layers

It is common to use both, but they solve different problems.

Mule Batch Processing controls how Mule handles a large record-oriented workload internally.

Salesforce Bulk API 2.0 controls how Salesforce accepts or returns a large dataset through its API.

A design can therefore look like:

Source
  ↓
Mule Batch Job
  ↓
Transform / validate
  ↓
Aggregate records
  ↓
Salesforce Bulk API 2.0

Do not assume that using a Mule Batch Job means Salesforce calls should still be made one record at a time.

Quick Decision Guide

Requirement	Likely direction
One/few records with immediate response	REST-style operation
Large asynchronous ingestion	Bulk API 2.0
Large asynchronous SOQL extraction	Bulk API 2.0 Query
Stable source identifier for sync	consider bulk upsert + External ID
Need independent Mule record processing	Mule Batch may complement Bulk API
Need immediate transaction semantics	evaluate synchronous APIs instead

Practical Rule

When the integration becomes dominated by the overhead of moving individual records across the network, reconsider the API boundary.

Bulk API 2.0 lets Salesforce process a dataset as a job, which is often a better architectural match for high-volume background integrations than simply increasing MuleSoft concurrency.