Salesforce API limits: why orgs blow the daily allowance and how to fix it

At 9:40 on a Monday morning, the ecommerce sync stops. Orders keep landing in the storefront; none of them reach Salesforce. The middleware dashboard is a wall of HTTP 403s, every one carrying the same code: REQUEST_LIMIT_EXCEEDED. Nobody deployed anything over the weekend. Nobody changed a mapping. The org has simply run out of API calls, and it will stay out until its rolling 24-hour usage falls back under the ceiling — which, with the middleware retrying every failure, may take a while.

This is how most teams learn that the Salesforce API allowance exists. That’s a shame, because the allowance is generous, it’s predictable, and the maths behind it fits on an index card. What kills orgs isn’t the limit; it’s that API calls feel free right up until they aren’t, so nobody budgets them. Three integration tools poll the same objects every minute, a legacy script writes records one at a time, a retry loop hammers a failing endpoint all night — and each one looked harmless when it shipped.

This guide covers how the daily allowance is actually computed, what counts against it and what quietly doesn’t, the four consumption patterns behind almost every REQUEST_LIMIT_EXCEEDED incident we see, how to find out where your calls are really going, and the fixes — batching, Bulk API 2.0, event-driven sync, caching, and disciplined retries — that cut usage by an order of magnitude.

How Salesforce computes your daily API allowance

The formula is simple: an edition base, plus an amount per user licence, plus anything you’ve bought as an add-on, all measured over a rolling 24-hour window — not a calendar day. Salesforce publishes the exact numbers in the API Request Limits and Allocations quick reference, and they’re worth checking against your own contract, but as of March 2026 the headline figures are:

Edition	Daily allowance	Per full Salesforce licence
Developer Edition	15,000 (flat)	—
Enterprise / Professional (API enabled)	100,000 base + licences + add-ons	+1,000
Unlimited / Performance	100,000 base + licences + add-ons	+5,000
Full sandbox	5,000,000 (flat)	—

So an Enterprise org with 80 Salesforce licences gets 100,000 + 80,000 = 180,000 calls per rolling day. The same org on Unlimited gets 500,000 on top of the base. Not every licence contributes equally: a Lightning Platform - One App licence adds 200 calls, Customer Community licences add zero, and External Identity licences add anywhere from 70,000 to 4,000,000 depending on tier. If your allowance seems oddly low for your headcount, this table is usually why — a hundred Community licences add nothing at all.

If legitimate volume genuinely exceeds the formula, you can buy more. Salesforce sells API call add-ons in increments ranging from 200 to 10,000 calls per day, and for some architectures — heavy external identity, high-frequency order flow — that’s the honest answer. It shouldn’t be the first answer, though, for reasons the rest of this post makes plain.

Two behaviours of the limit surprise people. First, it’s initially soft: Salesforce states that when you cross the daily allowance, further calls aren’t immediately blocked and continue to be processed if it’s safe to do so — but if usage keeps climbing, a system protection threshold kicks in and everything gets a 403 with REQUEST_LIMIT_EXCEEDED until the rolling window drains. Don’t design for the grace; it exists to absorb spikes, not to fund them.

Second, the same error code has a second meaning. Production orgs are capped at 25 concurrent long-running API requests — requests running 20 seconds or longer — and exceeding that cap also returns REQUEST_LIMIT_EXCEEDED, even if you’ve used a fraction of your daily allowance. If the error appears in bursts during business hours while the daily gauge reads 30%, you have a concurrency problem (usually slow queries), not a volume problem. Different diagnosis, different fix.

What counts against the limit — and what quietly doesn’t

The daily allowance is charged against the aggregate of REST API, SOAP API, Bulk API, and most Connect REST calls made to the org. Every GET on a record, every SOQL query via the API, every single-row POST from your middleware — one call each. This is the meter that matters, and it’s the one your integrations spin.

Just as important is what draws from other meters, because those other meters are the escape hatches:

• Bulk API record volume. The HTTP calls that create and manage a Bulk job count as ordinary API requests — but there are only a handful per job. The records themselves are governed by a separate allocation: 15,000 batches per rolling 24 hours, shared between Bulk API and Bulk API 2.0, at up to 10,000 records per batch — roughly 150 million records a day. In Bulk API 2.0, only ingest jobs consume batches; query jobs don’t, and batching is handled for you automatically.
• Streaming and event delivery. Platform Events and Change Data Capture events delivered to CometD, Pub/Sub API, or empApi subscribers draw on a separate daily event delivery allocation — by default 25,000 events per day on Enterprise Edition and 50,000 on Unlimited and Performance. Publishing through Pub/Sub API, Apex, or Flow doesn’t consume daily API requests either; publishing through REST or SOAP does.
• Composite requests. A composite call bundles up to 25 subrequests into one HTTP request, and the entire series counts as a single call toward your API limits. sObject Collections do the same for homogeneous operations, at up to 200 records per request.

Read that list again with a budget hat on. Salesforce charges you per HTTP round trip, not per record or per unit of work. Which means the entire game of staying under the limit is increasing the amount of work each round trip carries — or moving the work to a channel with its own meter.

Four ways orgs burn the allowance without noticing

When we’re asked to diagnose an org that keeps hitting REQUEST_LIMIT_EXCEEDED, the culprit is almost always one of four patterns. Usually two of them at once.

1. Chatty middleware polling. The default sync mode for most iPaaS connectors is “ask Salesforce what changed”, on a timer. The arithmetic is brutal. One connector polling one object every 60 seconds is 1,440 calls a day. Poll ten objects and it’s 14,400. Run three such tools — CRM-to-marketing, CRM-to-ERP, CRM-to-warehouse — and you’re at 43,200 calls a day, mostly asking questions whose answer is “nothing changed”. On a 180,000-call Enterprise org that’s a quarter of the allowance spent on silence, before a single record moves.

2. Per-record integrations. A nightly job upserts 40,000 rows, one REST call each: 40,000 calls. The same job through sObject Collections at 200 records a call: 200 calls. Through one Bulk API 2.0 ingest job: a handful of calls plus four batches from a 15,000-batch allocation. Row-by-row writing is a 200x tax that hides in code reviews because each individual call looks perfectly reasonable.

3. Unbatched, undelta’d syncs. Some syncs re-fetch entire tables nightly because delta logic was deferred to phase two, and phase two never came. Full refreshes multiply both the query calls and the write calls, and they get worse every month as the data grows — which is why these orgs fail suddenly, on no deploy, the week the account table crosses a threshold.

4. Runaway retries. A downstream failure starts returning errors; the client retries immediately, in a loop, all night. Failed calls count. We’ve seen a single misconfigured retry policy consume more of an org’s daily allowance than every legitimate integration combined — and the crueller version is retrying REQUEST_LIMIT_EXCEEDED itself, which keeps the rolling 24-hour window topped up and extends the outage the retries are trying to escape.

Underneath all four sits a governance gap: every integration authenticates as the same “integration user”, so consumption can’t be attributed, so nobody owns the budget. Fixing attribution is where diagnosis starts.

How to see where your API calls are going

Salesforce gives you four levels of visibility, from a glance to a forensic audit. Use all of them.

Setup pages. System Overview shows the last 24 hours of API usage as a percentage of your daily limit; Company Information shows the raw “API Requests, Last 24 Hours” figure alongside your monthly entitlement. Both are described in Salesforce’s own guide to monitoring API usage. Good for confirming a problem; useless for finding its source.

API Usage Notifications. In Setup you can configure email alerts when usage crosses a percentage threshold in a given interval — Salesforce’s guidance suggests tiers like 50%, 80%, and 90%. Send them to a shared inbox that someone actually reads. This is the single cheapest way to turn a Monday-morning outage into a Thursday-afternoon email.

The REST limits resource. For anything programmatic — middleware health checks, a dashboard, a pre-flight check before a big load — call the limits endpoint, available since API v29.0 to users with the View Setup and Configuration permission:

curl https://yourInstance.my.salesforce.com/services/data/v62.0/limits \
  -H "Authorization: Bearer $ACCESS_TOKEN"

The response returns maximum and remaining values for every org allocation, accurate within about five minutes:

{
  "DailyApiRequests": {
    "Max": 180000,
    "Remaining": 3421
  },
  "DailyBulkApiBatches": {
    "Max": 15000,
    "Remaining": 14996
  }
}

A well-behaved integration checks Remaining before starting a large run and yields when the budget is thin. Ordinary REST responses also carry a running usage figure in the Sforce-Limit-Info header, so long-running clients can watch consumption without extra calls.

Event Monitoring and the API Total Usage event. To find out who is spending the calls, you need the event log. The API Total Usage event type records the API requests that count against your limits — user, client IP, connected app, API family, status code — and Enterprise, Unlimited, Performance, and Developer orgs get these log files with one-day retention at no additional cost; longer retention needs the Event Monitoring add-on. Group a day’s log by CONNECTED_APP_ID and the league table of consumers usually answers the question in about ten minutes. This is also the argument for giving every integration its own connected app and its own dedicated integration user: without that separation, the log can’t tell your ERP sync from your marketing tool.

Five fixes that cut API consumption

Once you know where the calls go, the fixes follow. In rough order of effort-to-payoff:

1. Batch every record operation. No integration should ever write one record per call. For homogeneous operations, sObject Collections handle up to 200 records in a single request. For heterogeneous, dependent operations — create a parent, then children referencing it — a composite request does the whole unit of work in one call. Here’s the shape of it:

POST /services/data/v62.0/composite
{
  "allOrNone": true,
  "compositeRequest": [
    {
      "method": "POST",
      "url": "/services/data/v62.0/sobjects/Account",
      "referenceId": "newAccount",
      "body": { "Name": "Northwind Traders" }
    },
    {
      "method": "POST",
      "url": "/services/data/v62.0/sobjects/Contact",
      "referenceId": "newContact",
      "body": {
        "LastName": "Fuller",
        "AccountId": "@{newAccount.id}"
      }
    }
  ]
}

Two creates, one transaction boundary via allOrNone, one API call charged. The reference-ID syntax is case-sensitive — @{newAccount.id} matches the lowercase id field in the create response — and up to 5 of the 25 subrequests can be queries or sObject Collections, which covers most integration units of work.

2. Move real volume to Bulk API 2.0. Anything above a few thousand records per run belongs in a Bulk job, where the meter is batches, not calls. Bulk API 2.0 removed the old requirement to manage batches yourself — you create a job, upload the data, and Salesforce chunks it internally. The nightly 40,000-row sync that cost 40,000 REST calls becomes a rounding error against a 15,000-batch daily allocation that most orgs never come close to touching.

3. Replace polling with events. This is the structural fix. Change Data Capture publishes a change event whenever a record is created, updated, deleted, or undeleted — no polling, no “did anything change?” calls, and delivery draws on the event allocation rather than the API request allocation. The caveats are real: by default you can select only 5 entities for change notifications, and the default delivery allocation is 25,000 events per day on Enterprise — production-scale CDC usually means the add-on, which lifts the entity cap and adds delivery capacity in 100,000-events-per-day increments. Sizing that trade-off is an architecture decision, and it’s covered in more depth in our guide to Salesforce integration patterns.

4. Cache what doesn’t change. Middleware re-fetches an astonishing amount of static data: object describes, picklist values, record types, currency tables, the same account looked up once per order line. Cache reference data with a sensible TTL and de-duplicate lookups within a run. In practice this alone often claws back a meaningful slice of consumption, and it makes everything faster as a side effect.

5. Retry with backoff, and treat 403 as a stop sign. Every client needs exponential backoff with jitter, a retry cap, and a circuit breaker that stops calling a failing endpoint entirely. And REQUEST_LIMIT_EXCEEDED specifically must never be retried on a short fuse — the window is rolling, so hammering it is self-sustaining. Park the work, alert a human, and resume when the limits endpoint shows headroom.

None of these fixes is exotic. That’s rather the point — orgs blow the allowance through accumulated defaults, and they get it back through accumulated discipline. If the consumption profile is tangled enough that you can’t tell which fix goes where, that’s the moment to bring in outside help on the integration architecture rather than buying add-on calls to paper over it.

The allowance is an architecture signal, not a bill

It’s tempting to file API limits under procurement: usage high, buy more, move on. Sometimes that’s right — an org doing genuine high-frequency, high-volume work has a real case for add-on capacity, and Salesforce will happily sell it. But in our experience, an org that consumes its allowance on polling, per-record writes, and retries isn’t under-provisioned. It’s over-chatty, and the meter is the only place that chattiness becomes visible.

Looked at that way, the daily allowance is one of the more useful architecture reviews you’ll ever get, and it runs every 24 hours for free. High consumption with low business volume means work is being done in the wrong pattern — pull where push belongs, rows where batches belong, hope where backoff belongs. The same redesigns that cut API usage also cut latency, integration lag, and the 2 a.m. incident rate, because round trips are where all of those live.

So treat the number the way you’d treat a performance budget. Know your formula. Alert at thresholds. Attribute every call to a named integration. And when consumption climbs faster than the business does, read it as the platform telling you — precisely, and earlier than your users would — where the architecture owes something. Teams that internalise that stop being surprised on Monday mornings, and start catching next quarter’s incident in this quarter’s event logs. That’s the capability worth building: not a bigger allowance, but an integration estate that doesn’t need one.

Understanding the basics

How many API calls do you get in Salesforce?

It depends on edition and licences. Developer Edition orgs get a flat 15,000 API requests per rolling 24-hour period. Enterprise and API-enabled Professional orgs get 100,000 plus 1,000 per full Salesforce licence; Unlimited and Performance orgs get 100,000 plus 5,000 per licence. Some licence types add less or nothing, add-on packs can raise the total, and full sandboxes get a flat 5,000,000. The authoritative numbers live in Salesforce’s API Request Limits and Allocations documentation.

What does REQUEST_LIMIT_EXCEEDED mean in Salesforce?

It means Salesforce is refusing API calls, for one of two reasons. Either your org’s aggregate API usage over the trailing 24 hours has exceeded the daily allowance far enough to trigger system protection — every call then returns HTTP 403 until usage drains below the limit — or you’ve exceeded the concurrency cap of 25 simultaneous long-running requests. Check your daily usage first; if it’s low, the problem is slow requests, not too many of them.

Do Bulk API and Platform Events count against the daily API limit?

Mostly no, and that’s the point of using them. Bulk API job-control calls count as ordinary API requests, but the records are processed against a separate allocation of 15,000 batches per 24 hours. Platform Event and Change Data Capture delivery draws on its own daily event allocation, and publishing via Pub/Sub API, Apex, or Flow doesn’t consume API requests at all. Moving volume onto these channels is the standard way to relieve pressure on the daily limit.

---

Watching API consumption creep toward the ceiling in your org? Talk to us — untangling integrations before they go dark is what we do.