2.0 Now, 1.0 for What Only It Does
Module 3 of 8 in the chapter Moving Data at Scale, chapter 10 of the Integration Architect course. Each module stands on its own. Previous: A Job, Call by Call · Next: Parallel and Locking
The question this module answers: Salesforce has two Bulk APIs. Which one should your program use, and why is the old one still here?
When I taught this in 2024, I called them the fancy new 2.0 and the ancient 1.0. Both are loading docks at the back of the same bank. Both take a job, process it in the background, and hand you results. But they work differently, and a program you write today will live with its choice for years.
Data Architect’s Two Loading Docks covers the two for a one-time migration. This module looks at them from the program’s side: the calls, the sign-in, and what you’re signing up for.
Salesforce Has Picked a Side
Section titled “Salesforce Has Picked a Side”Salesforce’s guide is direct about it. The original Bulk API “is available”, but “use Bulk API 2.0 instead of Bulk API if you want a more streamlined workflow”, and “Bulk API 2.0 also has the advantage of future innovation” (What’s the Difference Between Bulk API 2.0 and Bulk API? (opens in a new tab), Bulk API 2.0 and Bulk API Developer Guide, Winter ‘27, checked 2026-11-01).
That last part has come true. Everything new since my 2024 class has landed in 2.0: downloading query results in parallel (Winter ‘25), and the job events of module 2 (Spring ‘25, still a Beta). Nothing new has landed in 1.0.
So 2.0 is where you start. Then the guide adds one more sentence: “If the feature set and limits are a unique match to your project requirements, use Bulk API.” That’s why 1.0 is still here.
The Same Job, Two Ways
Section titled “The Same Job, Two Ways”Here’s an insert job on each dock. On 2.0, it’s module 2’s five calls: open the job, upload one CSV, mark it UploadComplete, ask until it’s done, download the results. Salesforce splits your file into batches for you, runs them, and retries the ones that fail.
On 1.0, the address is different, and so is everything after it:
POST /services/async/68.0/jobX-SFDC-Session: <a session ID>Content-Type: application/xml; charset=UTF-8
<?xml version="1.0" encoding="UTF-8"?><jobInfo xmlns="http://www.force.com/2009/06/asyncapi/dataload"> <operation>insert</operation> <object>Account</object> <contentType>CSV</contentType></jobInfo>Then your program does the work 2.0 does for you:
- It makes the batches. It cuts the data into pieces of up to 10,000 records and sends each one to
/job/<job ID>/batch(Bulk API and Bulk API 2.0 Limits and Allocations (opens in a new tab), checked 2026-10-31). In Salesforce’s words, “It’s up to the client to decide how to divide the entire data set” (Work with Batches (opens in a new tab), checked 2026-11-01). - It closes the job, with the state
Closed, so no more batches can be added. - It watches every batch, not just the job:
Queued,InProgress,Completed,Failed,NotProcessed. - It collects the results batch by batch, and puts them back together.
It’s the same five steps, with more calls and more code. That’s what “a more streamlined workflow” means.
Why 1.0 Is Still Here
Section titled “Why 1.0 Is Still Here”Four things only 1.0 does. Each one is a real reason, and each one is rare.
| Only in 1.0 | When you’d want it | Where it’s taught |
|---|---|---|
Serial mode. The job’s concurrencyMode can be Serial, one batch at a time. 2.0 jobs always run in parallel. | Locking that sorting the file by parent didn’t fix | Module 4 |
| Your own batch size. You decide how many records go in each batch. | Heavy automation on the object. As I said in class: a lot of automations, a smaller batch size | This module |
| XML, JSON and attachments. 2.0 takes CSV only. 1.0 also takes XML and JSON, and zip files with binary attachments. | A source system that only produces XML or JSON, or an old load of files | This module |
| Manual PK chunking. You switch it on and set the chunk size. 2.0 chunks for you. | Control over a very large export; and recognizing it on the exam | Module 5 |
If none of those four is on your list, you’re on 2.0.
The Sign-In
Section titled “The Sign-In”This is the part that has changed since 2024, and it isn’t in the feature table.
2.0 signs in like every other REST API in chapter 8: an OAuth access token in the Authorization: Bearer header. 1.0 doesn’t. Salesforce’s guide still documents one way in: “The Bulk API doesn’t provide a login operation, so you must use SOAP API to log in”, and every request carries the session ID from SOAP’s login() call in its own header, X-SFDC-Session (Step 1: Log In Using the SOAP API (opens in a new tab), checked 2026-11-01). We tried the 2.0 way on 1.0 in our own Developer Edition org: a bearer header gets InvalidSessionId, “Unsupported Authorization scheme.”
And SOAP login() is going away. Salesforce’s dates (Platform SOAP API login() Retirement & new Security Requirements (opens in a new tab), Salesforce Help, updated 2026-10-09, checked 2026-11-01):
| When | What changes for login() |
|---|---|
| Already | Not available in API 65.0 and later. Off by default in orgs created from Winter ‘26. |
| 1 December 2026 | Works only for users with the Use Any API Auth permission. |
| 15 December 2026 (sandboxes), 31 January 2027 (production) | From a broad login IP range, it needs a security token. And it’s turned off in orgs that haven’t used it in six months. |
| Summer ‘27 | Retired in versions 31.0 to 64.0. “Calls fail.” |
Salesforce’s advice is to “migrate to external client apps and OAuth” (chapter 13 teaches both). So every 1.0 program in your landscape has a deadline. For each one, find out how it signs in today, and how it will sign in after Summer ‘27. If it can move to 2.0, move it. If it really needs 1.0, get a clear answer from whoever owns it, a vendor or your own team, before the dates arrive, not after.
Watch the six-month rule. A once-a-year job, a disaster-recovery load, a seasonal feed: if it’s the only thing in the org still calling login(), it can look unused, get turned off, and fail the next time it runs.
To find them, Salesforce points to Login History, and to the API Total Usage log from chapter 8 module 1: a call with an empty connected app ID came in through login() or a session.
Which Dock?
Section titled “Which Dock?”At Steve Trucking, every bulk feed runs on 2.0: Keystone’s nightly status file, the weekly export to Snowflake, and the RouteDesk migration. The one place 1.0 could show up is the migration. If sorting the Work Orders by parent doesn’t stop the locking, Data Architect’s fallback is a rerun in serial mode, and only 1.0 has it. That’s a choice for one night, made on purpose, with its sign-in planned. It’s not where the nightly feeds live.
The tools on top make the same choice for you. In class I said the bulk API is the main gateway for getting data in and out: the data loaders, the ETL tools, the integration platforms all sit on it. Most of them offer both docks. Ask which one each tool uses for each job, and how it signs in.
Test knowledge. Know the two Bulk APIs apart. Bulk API 2.0: OAuth, CSV only, Salesforce makes the batches and chunks queries for you, limited by records a day, and it’s the one Salesforce recommends. Bulk API 1.0: a session ID in the
X-SFDC-Sessionheader, CSV, XML, JSON and attachments, batches you make (up to 10,000 records each), serial mode, and PK chunking you switch on, limited by batches a day. Both are asynchronous, and both share the 15,000 batches a day.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- Which dock each bulk job uses. 2.0, unless it needs one of the four things only 1.0 does. Write the reason down when it’s 1.0.
- How every 1.0 program signs in, and after Summer ‘27. Find them all, including the rare ones, before the December and January steps.
- Which dock the tools use. The data loader, the ETL tool, the vendor’s connector: ask, and put the answer in the landscape inventory from chapter 5.
- When a 1.0 job moves to 2.0. Every time you touch one, ask whether it still needs what only 1.0 does.
Explore
Section titled “Explore”- What’s the Difference Between Bulk API 2.0 and Bulk API? (opens in a new tab): Bulk API 2.0 and Bulk API Developer Guide, Winter ‘27, the comparison table (checked 2026-11-01)
- Work with Batches (opens in a new tab) and JobInfo (opens in a new tab): the same guide, Bulk API 1.0’s batches and job settings (checked 2026-11-01)
- Platform SOAP API login() Retirement & new Security Requirements (opens in a new tab): Salesforce Help, the dates and how to find the callers (checked 2026-11-01)
- Bulk API and Bulk API 2.0 Limits and Allocations (opens in a new tab): Salesforce Developer Limits and Allocations Quick Reference (checked 2026-10-31)
- Loading at Volume: the Data Architect course, the two docks for a migration
- Salesforce Developers, Bulk API 2.0 and Bulk API Developer Guide, Step 1: Log In Using the SOAP API (opens in a new tab), checked 2026-11-07.