Large Salesforce data migrations rarely fail because the data is impossible to move. They stall because the migration runs into the org's API limits halfway through a load window, while production integrations are competing for the same daily allowance.
API limits are easy to ignore during planning because they don't show up in a mapping spreadsheet. They show up at 2 a.m. on cutover weekend, when a load job starts returning errors and the integrations your business depends on stop syncing.
This guide explains how Salesforce API limits work, why migrations use more calls than teams expect, and how to plan capacity before your first full load.
Quick Answer
Salesforce API limits during a data migration are the daily and concurrent caps on inbound API calls that every load job, lookup, and validation query counts against, alongside your existing integrations. For Enterprise Edition orgs, the daily allocation is 100,000 calls plus a per-license amount and any purchased add-ons. To plan, estimate calls per object, use the Bulk API for high-volume loads, schedule loads around production integrations, monitor usage daily, and talk to your Salesforce account team early if you need a temporary increase. This matters for any team moving large data volumes into Salesforce, and it is part of every migration plan Vantage Point builds.
Key Takeaways (TL;DR)
- Migrations share the budget: load jobs count against the same daily allocation as your production integrations.
- Calls add up beyond inserts: ID lookups, retries, validation queries, and polling all consume calls.
- Use the right API: the Bulk API moves large volumes in far fewer requests than record-by-record loads.
- Some records need a second pass: fields that can't be matched by external ID require querying back record IDs first.
- Ask early: temporary allocation increases and licensing questions take time, so raise them before the load window.
What Are Salesforce API Limits?
Salesforce limits API usage to keep the platform stable for all customers. For its SOAP and REST APIs, and APIs built on them, Salesforce applies three types of limits:
- Total API request allocations: the number of inbound calls allowed in a rolling 24-hour period.
- Concurrent request limits: production orgs and sandboxes allow 25 concurrent long-running requests (those lasting 20 seconds or more). Shorter requests are not limited this way.
- Timeout limits: REST and SOAP calls time out after 10 minutes, except query calls, which follow SOQL limits.
For Enterprise Edition orgs, the daily allocation is 100,000 calls, plus a per-license amount for each user license (1,000 per full Salesforce license), plus any API call add-ons you've purchased. Unlimited and Performance Edition licenses carry a higher per-license amount. Your exact number depends on your license mix, so check it in your org rather than estimating.
Why Do Data Migrations Hit API Limits?
Teams usually estimate API usage by counting records. That misses most of the work. A realistic migration also includes:
- Lookups and crosswalks: querying records you already loaded to get their Salesforce IDs for child records.
- Retries: failed batches that are fixed and reloaded, sometimes several times.
- Validation queries: counts and spot checks after each load.
- Job polling: tools checking on the status of asynchronous jobs.
- Existing integrations: marketing automation, telephony, ERP, and data warehouse syncs that keep running during the migration.
- Automation side effects: triggers and flows that fire on loaded records and call out to other systems.
On top of that, migrations are uneven. A test load might use a small share of your allocation, while the full historical load of activities, notes, and attachments can use many times more in a single day.
Which API Should You Use for a Migration?
| Approach | Best for | API impact | Watch out for |
|---|---|---|---|
| Bulk API 2.0 | High-volume loads of standard and custom objects | Large batches mean far fewer requests per record | Its own batch, record, and CPU time allocations; asynchronous processing |
| REST composite requests | Moderate volumes, related records created together | Several operations per request | Timeouts apply to the whole composite request |
| Record-by-record REST or SOAP | Small volumes and fixes | One call per operation | Burns through allocations quickly at scale |
| Data Loader or ETL tools | Admin-run loads and repeatable jobs | Depends on whether the tool uses Bulk or SOAP mode | Confirm the mode; defaults are not always Bulk |
For most large migrations, the Bulk API does the heavy lifting and REST handles the edge cases. The Bulk API has its own limits, including a dedicated server-side CPU time limit for bulk processing, so check the Bulk API limits documentation for your volumes.
Why Do Some Records Need Actual Salesforce IDs?
The cleanest way to link related records during a load is with external IDs: you load parents with their legacy IDs, then load children that reference those legacy IDs, and Salesforce resolves the relationship. That avoids extra lookups.
Not every field works that way. Polymorphic lookups, which can point to more than one type of object, and some objects such as feed posts and notes may need the actual Salesforce record ID, depending on the object and the tool. In those cases, the plan needs an extra step:
- Load the parent records with their legacy IDs stored in an external ID field.
- Query back the Salesforce IDs and legacy IDs to build a crosswalk.
- Transform the dependent records to reference Salesforce IDs.
- Load the dependent records and validate the links.
Each of those steps uses API calls, and the crosswalk has to be rebuilt if parents are reloaded. Document these cases in your data migration mapping document so the load order and call estimate account for them.
How Do You Estimate API Usage for a Migration?
A simple estimate beats no estimate. Build it object by object:
- List every object and its record count, including activities, notes, and files.
- Choose the load method for each object and calculate requests from the batch size.
- Add lookups and validation queries for each object with dependent records.
- Add a retry buffer for batches that fail and are reloaded.
- Subtract what production already uses. Check your normal daily usage so you know how much headroom exists.
- Spread the plan across days so no single day exceeds the headroom you have.
Run a representative test load in a full sandbox and compare actual usage with your estimate. Then adjust before production.
What Happens If You Exceed the Daily Limit?
Salesforce allows paid orgs in active status to go over their daily allocation by a limited amount during occasional spikes, subject to a hard cap and the health of the instance. Salesforce is clear that this is meant for occasional use and should not be relied on. API activity is aggregated into 30-day periods starting from your contract start date, and those totals include calls over the entitled limit.
If you reach the hard cap, calls fail until usage drops back under the limit. During a migration, that can mean both your load jobs and your production integrations stop working at the same time.
How Can You Get More API Capacity?
- Reduce calls first. Switch high-volume objects to the Bulk API, increase batch sizes, and turn off unnecessary automation during loads.
- Pause or throttle non-critical integrations during the heaviest load days.
- Buy more capacity. Salesforce sells API call add-ons and additional licenses through the Your Account app or your account executive.
- Ask about a temporary increase. For short, planned spikes, talk with your Salesforce account team about options well before your load window, and confirm exactly when any temporary change starts and ends.
Also check your integration platform. If it is licensed by flows, cores, or message volume, find out how usage is measured. Some licensing models look at peak usage during a billing period, so a short migration spike can count even after usage drops. Raise that question before the spike, not after the invoice.
How Should You Monitor API Usage During the Migration?
- Check the API request usage shown in Setup, and run the API usage reports available in your org.
- Query the REST
/limitsresource from your load tooling so jobs can pause before hitting the cap. - Set alerts at meaningful thresholds so someone is notified before the limit is reached.
- Review usage by integration user so you know which system is consuming what.
If your Salesforce org also syncs with a marketing platform, our guide to HubSpot-Salesforce API limits explains how that sync consumes calls.
What Should Businesses Do Next?
Add an API capacity section to your migration plan now, before test loads begin. Record your daily allocation, your normal production usage, the estimated calls per object, and the load schedule. Identify the objects that need ID crosswalks, confirm which tools use the Bulk API, and name the person who watches usage during each load. If the numbers don't fit, start the conversation with your account team early. Capacity changes, licensing questions, and approvals all take longer than a load window allows.
How Vantage Point Helps
Vantage Point plans and runs large Salesforce migrations with API capacity built into the plan from day one. Our system integration and data migration team estimates call usage, sequences loads, and builds the crosswalks that tricky relationships need. Our MuleSoft integration services help design integration architecture that fits both the migration spike and steady-state operations. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Planning a Large Salesforce Data Migration?
Don't let API limits decide your cutover date. Vantage Point can review your load plan, estimate API usage, and help you move data without disrupting production. Talk to Vantage Point about your Salesforce migration.
Frequently Asked Questions
How many API calls does a Salesforce org get per day?
For Enterprise Edition, the daily allocation is 100,000 calls plus a per-license amount for each user license and any purchased API call add-ons. Unlimited and Performance Edition licenses carry higher per-license amounts, so check the exact figure in your org.
Do data migration loads count against Salesforce API limits?
Yes. Loads, lookups, validation queries, and job status checks all count against the org's API limits, alongside every production integration that is running at the same time.
Does the Bulk API use fewer API calls?
Yes, for large volumes. The Bulk API processes records in large batches, so it needs far fewer requests than loading records one at a time. It has its own batch, record, and processing limits that you should check against your volumes.
What happens when a Salesforce org exceeds its API limit?
Salesforce allows limited overage for paid orgs during occasional spikes, subject to a hard cap. Once the cap is reached, API calls fail until usage drops, which can stop both migration jobs and production integrations.
Can you get a temporary Salesforce API limit increase?
Talk with your Salesforce account team about options for planned spikes such as migrations. Salesforce also sells API call add-ons and additional licenses. Ask early, and confirm when any change takes effect and when it ends.
Why do some migrated records need Salesforce IDs instead of external IDs?
Some fields, such as polymorphic lookups, and some objects, such as feed posts, may not resolve relationships by external ID, depending on the object and tool. Those records need a crosswalk built by querying back the Salesforce IDs of loaded parent records.
How do you monitor Salesforce API usage during a migration?
Watch API usage in Setup and API usage reports, query the REST limits resource from load tools, set alerts at key thresholds, and review usage by integration user to see which system is consuming calls.
