Salesforce API limits cap how many calls outside systems can make into your org. The main one is a daily request allocation, counted across the whole org over a rolling 24 hours. Its size depends on your edition and the licenses you own. A second limit restricts how many slow requests can run at once. Integrations stay inside both by sending fewer, larger, event-driven calls instead of constant small ones.
How is the daily API request allocation calculated?
For Enterprise, Unlimited and Performance editions, the allocation is a fixed base plus an amount per license, plus any API call add-ons you buy. Developer Edition orgs get a small flat number instead.
Salesforce documents the structure on developer.salesforce.com, in the page titled API Request Limits and Allocations. For paid editions the formula reads as a base of 100,000 requests, plus licenses multiplied by calls per license type, plus purchased add-ons. Each full Salesforce or Salesforce Platform license adds 1,000 calls in Enterprise Edition and 5,000 in Unlimited or Performance. Community, partner and login-based licenses add far less, and some add nothing. Professional Edition only qualifies once API access is enabled.
Salesforce gives its own worked example: an Enterprise org with 15 Salesforce licenses gets 115,000 requests per 24 hours. Full sandboxes not built from a template get a much larger flat allocation. Values change between releases, so read the current page before you budget against them.
Two details trip people up. The window is rolling, not reset at midnight, so a heavy job at 5 a.m. still counts until 5 a.m. tomorrow. And the allocation belongs to the org as a whole, never to an individual user or integration.
Which calls count against the limit, and which do not?
REST, SOAP, Bulk API, Bulk API 2.0 and most Connect REST calls all draw from the same daily pool. Calls from some Salesforce-owned connected apps, such as the mobile app, are excluded.
Calls made by installed managed packages count against your org, according to the same Salesforce page. That matters because AgentExchange (formerly AppExchange) tools often sync in the background with no obvious owner inside your team. Platform events and Change Data Capture are metered separately, which the section on events covers below.
What is the concurrent long-running request limit?
Production orgs and sandboxes can run 25 inbound requests lasting 20 seconds or longer at the same time. Developer Edition and trial orgs get 5.
Short requests have no concurrency cap. Once 25 slow calls are in flight, new ones fail with a REQUEST_LIMIT_EXCEEDED error until a slot frees up. This limit usually bites during month-end jobs, heavy reports pulled through the API, or unselective queries against large objects. Separately, ordinary REST and SOAP calls time out after 10 minutes, with query timeouts governed by SOQL limits instead.
If you see concurrency errors, look first at query selectivity and at integrations that open many parallel threads. Adding retries without backoff usually makes the pile-up worse.
Should integrations use REST, Composite or Bulk API?
Pick the API by record volume and how quickly the target needs the change. Salesforce suggests Bulk API 2.0 for data operations above roughly 2,000 records, and bulkified synchronous calls below that.
| Workload | Better fit | Effect on the daily allocation |
|---|---|---|
| Single record updated by a user action | REST API | One call per request, which is fine at low volume |
| Several related records written together | REST Composite resources | Salesforce counts the whole composite series as one call |
| Thousands of records loaded or extracted | Bulk API 2.0 | Counts toward the daily pool, but one job replaces many single calls |
| Downstream system needs to know a record changed | Change Data Capture or platform events | Uses separate event allocations rather than repeated polling queries |
| Showing external data without storing it | Salesforce Connect or a cached lookup | Shifts load away from frequent sync calls; confirm licensing first |
Bulk work has its own ceiling too. Bulk API and Bulk API 2.0 share an allowance of 15,000 batches per rolling 24 hours. In Bulk API 2.0, only ingest jobs consume batches, and query jobs are tracked against a separate job count. Very small batch sizes waste that allowance.
Do platform events and Change Data Capture have their own allocations?
Yes. Event publishing and event delivery are measured against their own allocations, separate from the daily API request pool.
Without an add-on license, Salesforce applies default publishing and delivery allocations that cannot be exceeded. An add-on for extra platform events or change events raises them and moves delivery to a monthly usage-based entitlement. Change Data Capture also limits how many objects you can select for change events without an add-on. Concurrent CometD subscribers have their own cap, which varies by edition. You can check event usage in Setup, through REST API, or by querying PlatformEventUsageMetric. Ask your Salesforce account team which event add-ons fit your contract.
Where can we see how many API calls we are using?
Setup shows current consumption on the System Overview page, and you can set up email alerts. For detail on who is calling, you need Event Monitoring log data.
- System Overview in Setup shows API usage and an API Requests, Last 24 Hours figure.
- The Company Information page shows API requests aggregated over 30 days as a usage-based entitlement.
- API Usage Notifications email a chosen user when consumption passes a percentage you set.
- REST responses carry a Sforce-Limit-Info header, and the /limits resource returns current values for scripts and dashboards.
- The API Total Usage event log records each request's connected app, user, API family, resource and whether it counted against the limit.
The API Total Usage log is the most useful of these when you need to find the culprit. Its client category field can flag requests from Agentforce agents and Salesforce-hosted MCP servers. Event log access depends on your Event Monitoring entitlement, so check with your account team what your org includes.
What actually happens when we hit the limit?
Salesforce may let a paid, active org run somewhat past its daily allocation during an occasional spike. Beyond a hard cap, calls are refused and integrations start failing.
Salesforce says this overage headroom is not meant for ongoing use and does not apply to trials, Developer Edition or sandboxes. Usage, including calls over the entitlement, is also aggregated into 30-day periods from your contract start date. So a habit of running over is visible to Salesforce even if nothing breaks that day. Treat the allocation as a hard budget and alert well before it.
What usually burns through the allocation?
Heavy usage usually traces back to a few integrations. They are rarely the ones anyone suspects.
- Polling jobs that ask every minute whether anything changed, even when nothing has.
- Middleware that writes one record per call and then reads it back to confirm.
- Data loader jobs run in single-record mode, or rerun after a partial failure.
- Managed packages that sync in the background on a schedule nobody set.
- AI assistants, agents and MCP tools that fetch records one at a time while reasoning through a task.
- Retry loops without backoff, which multiply calls exactly when the org is already struggling.
AI tooling deserves a closer look now. An agent that answers one question may issue dozens of reads, and nobody budgeted for them when it was approved.
Which design patterns keep integrations inside the limit?
Send changes rather than snapshots, group records into fewer requests, and stop asking Salesforce questions you already know the answer to.
- Event-driven sync: subscribe to change events or platform events rather than polling for updates.
- Delta sync: track a last-modified watermark and request only records changed since the previous run.
- Bulk for volume: move nightly loads and large extracts to Bulk API 2.0 with sensible batch sizes.
- Composite for related writes: combine dependent creates and updates into a single round trip.
- Caching: hold reference data such as products or price books in middleware, refreshed on a schedule.
- Backoff and circuit breakers: slow down or pause after limit errors instead of retrying immediately.
- One integration user per system: give each connection its own user so usage is easy to attribute.
If you run MuleSoft or another integration platform, rate-limiting policies at the gateway can throttle callers before they reach Salesforce. That turns the API allocation into something you govern, rather than something you discover.
Can we just buy more API capacity?
Often, yes. Salesforce sells extra API calls and additional licenses that raise the allocation, through the Your Account app or your account executive.
Salesforce itself recommends reviewing usage and reducing calls before buying more. Pricing and packaging differ by contract and shift over time. Your Salesforce account team can say what applies to you. Buying capacity without fixing a chatty integration only delays the next outage.
How should we plan API capacity before a new integration goes live?
Estimate calls per flow, add them up against the allocation, and leave headroom for growth and retries. Then set alerts so the estimate is checked against reality.
| Question | What to record | Why it matters |
|---|---|---|
| What is our current allocation? | Edition, license counts, add-ons and the System Overview figure | Sets the real ceiling rather than a remembered one |
| What do existing integrations use? | Calls per day by connected app or integration user | Shows how much headroom is actually free |
| How many calls will the new flow make? | Records per day, calls per record, API type and retry rate | Turns a design into a number you can test |
| When does the load peak? | Batch windows, month-end, campaign sends and business hours | Concurrency and daily totals both spike at peaks |
| What happens if a call fails? | Retry policy, backoff and who receives the alert | Prevents retry storms that consume the remaining budget |
| Who owns the number? | A named owner for each integration and its usage | Usage drifts upward when nobody is accountable |
What mistakes do teams make with API limits?
- Sizing a new integration from the vendor's estimate without measuring calls in a full sandbox first.
- Sharing one integration user across several systems, which makes usage impossible to attribute.
- Treating the overage headroom as extra capacity rather than an emergency buffer.
- Ignoring event allocations because the team assumed events were free.
- Approving AI agents or MCP connections with no estimate of the API reads they trigger.
- Setting usage alerts so high that the warning arrives after jobs have already failed.
Code running inside Salesforce faces a related set of controls called governor limits, which cap what one transaction can consume. Our glossary covers how the two differ. A health check can include an API usage review alongside automation and data quality.
