Salesforce doesn't give your integration a rate limit of its own. Each customer org has one daily pool of inbound API requests, sized by edition and licenses, and every tool connected to that org draws from it, your product included. An Enterprise Edition org gets 100,000 requests per rolling 24 hours plus 1,000 for each Salesforce license. No more than 25 calls lasting 20 seconds or longer can run at once, per Salesforce's API Request Limits and Allocations.
For a SaaS company that means the limit you design against is set by each customer's contract, shared with every other vendor they've connected, and paid for by them. Salesforce's own page tells admins that a partner app that "makes inefficient use of the API incurs unnecessary costs for your company." So the integration enterprise customers asked for is also the one they'll audit first when the org runs short. Appnigma works with B2B SaaS teams on exactly these customer-facing Salesforce integrations. Our done for you delivery builds and maintains them with a named integration engineer, and our marketplace apps work ships the native app when part of the logic should run inside Salesforce.
Updated October 2026. Checked against the Salesforce Developer Limits and Allocations Quick Reference, the REST API Developer Guide and the Salesforce Developers blog. The earlier version said Salesforce blocks calls as soon as the limit is reached, counted "200 records = 1 bulk call", and credited Salesforce Connect and External Services with automatic retries and rate awareness that Salesforce doesn't document. This update corrects those and adds the overage rule, what counts toward the pool, the managed package rule and a per-customer cost example.
The daily allocation by edition
The pool is calculated per org, not per user and not per connected app. Salesforce states that limits "are enforced against the aggregate of all API calls made to the org in a 24-hour period" and "are not on a per-user basis," on the allocations page. A dedicated integration user doesn't give your product a separate budget.
| Org type | Daily allocation (rolling 24 hours) |
|---|---|
| Enterprise, and Professional with the API add-on | 100,000 + 1,000 per Salesforce license + purchased add-ons |
| Unlimited and Performance | 100,000 + 5,000 per Salesforce license + purchased add-ons |
| Developer Edition | 15,000 |
| Full sandbox (not created from a template) | 5,000,000 |
Other license types add different amounts, for example 200 per Partner Community license and 10 per Partner Community Login license on the same page. Salesforce's own worked example gives an org with 15 Salesforce licenses "115,000 requests" a day. Professional Edition has no API access by default, and "Professional Edition orgs can add API access as an add-on," per Supported Editions and Required Permissions. A Professional customer without it gets API_DISABLED_FOR_ORG on your first call, so edition belongs on your install checklist.
The rolling window matters more than the number. Salesforce's Developer Edition example has an org that "made 14,500 calls at 5:00 AM Wednesday" and 499 more that night, after which "only one more call can successfully be made until 5:00 AM Thursday." A nightly backfill that spends most of the pool at 2 AM keeps the org short until 2 AM the next day, not until midnight.
Is there a per-second rate limit in Salesforce?
Not for the core REST and SOAP APIs. The two limits are the rolling 24-hour total and a concurrency cap on long requests. The cap covers "concurrent inbound requests (calls) with a duration of 20 seconds or longer," and it's 25 in production orgs and sandboxes and 5 in Developer Edition and trial orgs, per the allocations page. "There isn't a limit on the number of concurrent requests shorter than 20 seconds." Over the cap, the API returns REQUEST_LIMIT_EXCEEDED until fewer than 25 long calls are running.
Those 25 slots belong to the whole org. A slow report export from a BI tool, a data loader job and your product's large SOQL query all sit in the same 25. Keep queries selective and paginated so each call finishes well under 20 seconds, and your product stays out of that queue entirely. REST and SOAP calls also time out after 10 minutes, except queries, which follow the SOQL limits.
Two exceptions use per-hour limits. Chatter REST resources have a limit counted per user and application each hour, per Connect REST API Limits, and GraphQL follows the Connect limits and answers with a 503 when they're exceeded, per GraphQL API Request Limits. A 429 retry handler copied from another platform's client will never fire against core Salesforce endpoints.
What happens when a Salesforce org exceeds its API limit?
The first requests over the line usually still succeed. Salesforce "still lets the operations proceed by a certain amount, if possible," and "a hard cap is in place to safeguard platform resources," per the allocations page. Salesforce doesn't publish how large that margin is. It "only applies to paid orgs in active status" and not to trial orgs, Developer Edition or sandboxes, which is why a sandbox test can fail at a number production would have passed.
Past the hard cap, calls get HTTP 403 with a REQUEST_LIMIT_EXCEEDED error code. They "will only be unblocked when your Daily API Requests, as measured over the preceding 24-hours, falls back under this limit," per the Salesforce Developers post API Limits and Monitoring Your API Usage. Every integration in the org stops at that point, not only the one that pushed it over. The same post is direct about the margin: "you should not plan your normal business volumes based on exceeding your Daily API Request Limit."
The monthly figure customers see is reporting, not a second limit. Usage "is aggregated into 30-day periods, starting with your contract start date." Admins see it as the API Request Limit per Month entitlement on the Company Information page, and the blog states "there is no enforcement against the Monthly API Entitlement." When a customer forwards a screenshot of that page, the daily number is the one to discuss.
What counts against the pool and what doesn't
REST, SOAP, both Bulk APIs and "most Connect REST APIs" count, per the allocations page. The request shape decides how many calls a sync costs, and three REST resources do the most work for the fewest calls.
| Request | API calls counted | Source |
|---|---|---|
| Single REST or SOAP call | 1 | Allocations |
| Composite, up to 25 subrequests | 1 for the whole request | Composite |
| Composite Batch, up to 25 subrequests | 1 per subrequest | Composite Batch |
| sObject Collections, up to 200 records | 1 for the whole request | sObject Collections |
| Calls from an installed managed package | Count against the customer org | Allocations |
| Publishing events through REST, SOAP or Bulk API | Count | Platform event allocations |
| Publishing events through Pub/Sub API, Apex or flows | Don't count | Platform event allocations |
| Calls with DebuggingHeader | Separate 1,000 per 24 hours | Allocations |
Composite and Composite Batch look alike and are priced very differently. For Composite, "the entire series of requests counts as a single call toward your API limits." For Composite Batch, "each subrequest counts against rate limits." Our guide to Composite and GraphQL in Salesforce covers when each fits.
Bulk API jobs draw on the same daily pool and also have their own allocation of "up to 15,000 batches per rolling 24-hour period." That batch allocation is shared between Bulk API and Bulk API 2.0, per Bulk API and Bulk API 2.0 Limits. Salesforce suggests Bulk API 2.0 for operations above 2,000 records and composite calls below that. The record chunking inside a Bulk job is not the same as call counting, which is where "200 records = 1 bulk call" went wrong. The Bulk API 2.0 guide has the job-level numbers.
What one customer sync costs the org
Here is a worked example from the documented limits, not a measured customer. An Enterprise Edition customer has 50 Salesforce licenses. Its pool is 100,000 + 50 x 1,000 = 150,000 requests per 24 hours. Your product syncs six objects and writes back 20,000 record updates a day.
| Design | Calls per day | Share of 150,000 |
|---|---|---|
| Poll six objects every 5 minutes with a SOQL query each | 6 x 288 = 1,728, before pagination | 1.2% |
| Write 20,000 updates one record per call | 20,000 | 13.3% |
| Write 20,000 updates through sObject Collections, 200 per call | 100 | 0.07% |
| Replace polling with a Change Data Capture subscription | 0 daily API requests, uses event delivery instead | 0% of this pool |
The write path is where most of the cost hides. One-record writes cost 200 times what collections cost for the same data, and 13% of a customer's pool is enough for an admin to notice in the API Usage section of System Overview. Polling is cheaper than its reputation but grows with every object and customer you add, and a query that returns more than one page adds a call per page.
Moving to events changes which allocation you spend, not whether you spend one. Change Data Capture delivered through Pub/Sub API uses the org's event delivery allocation, 25,000 events per 24 hours on Enterprise and counted per subscribing client, per Default Platform Event Allocations. Our comparison of platform events and Change Data Capture works through that second budget.
How managed packages and in-org code are counted
A managed package is not exempt. Salesforce's note reads "API calls made from installed managed packages, count against your org limit," on the allocations page. Passing security review doesn't change that, and neither does an AppExchange listing.
What does change is where the work happens. The pool measures "the total inbound API requests (calls) per 24-hour period for an org." Logic your package runs inside the org, in Apex triggers, queueable jobs or flows, runs under the Apex execution governors per transaction instead of the inbound daily count. Salesforce says the same about related in-org paths, for example that server-side Aura actions "aren't counted against your org's API limits" and that publishing events from Apex or flows doesn't consume daily API requests. When the package needs your backend, it makes outbound callouts, limited to 100 per transaction and 120 seconds of total callout time.
That gives a SaaS vendor a real design choice. A sync that reads every change from outside costs the customer's pool. A native app that reacts to changes in a trigger and calls your service once per batch of records spends governor limits in each transaction instead, and those reset per transaction rather than per day. The trade is that the code now lives in the customer's org, ships as a package version, and goes through security review. Our post on governor limits in managed packages covers the limits that apply once it does, and what a native Salesforce app is covers the packaging side.
Reading usage from your own integration
Every REST response carries the org's current count. Salesforce documents the header as Sforce-Limit-Info: api-usage=10018/100000, where "the first number is the number of API calls used, and the second number is the API limit for the organization," per Limit Info Header. Your client can read it on calls it was making anyway, at no extra cost.
curl -s -D - -o /dev/null \
-H "Authorization: Bearer $ACCESS_TOKEN" \
"$INSTANCE_URL/services/data/v66.0/sobjects/Account/describe" \
| grep -i sforce-limit-infoThe /limits resource returns the same pool as DailyApiRequests with Max and Remaining, per List Org Limits, along with the Bulk and event allocations. It is itself a counted call, since the header page names only the Versions URI as free, so call it once per sync run rather than before every request. Store the ratio per customer org, and slow non-urgent work when it crosses a threshold you choose, rather than waiting for the 403.
Customer admins see the same pool in Setup under System Overview, and can turn on API Usage Notifications to email someone "when the number of API requests has exceeded a specified percentage of the amount allotted." Attribution is the next question they ask. The API Total Usage event log records each request with CONNECTED_APP_ID, CLIENT_NAME and COUNTS_AGAINST_API_LIMIT, per the API Total Usage event type. CLIENT_NAME "includes values passed via the Sforce-Call-Options header," so setting a client name on your requests lets an admin tell your traffic apart from the vendor next to you. Salesforce's blog post adds that "all orgs can view the daily API Total Usage event log files for the previous 24 hours."
Running this across a customer base is mostly operations work. Appnigma's integration infrastructure is built for that part, and lets your engineers "monitor each customer's connections, identify issues, and move fixes through the same review and release process."
Raising a customer's allocation
The customer buys more, not the vendor. Salesforce's docs say to "use Your Account App to buy additional user licenses or extra API calls." The Salesforce Developers blog lists add-ons "in increments ranging from 200 through 10,000 per 24-hour period." Before buying, Salesforce suggests the customer "consult with the vendor to verify that the product makes optimal use of the API," so expect that conversation to reach your support team. Publishing your product's expected daily call volume per object in the install guide answers it before it's a ticket.
Mistakes that show up after customers install
- Testing volume in a sandbox or Developer Edition org, where the overage margin doesn't apply and the pool is a different size.
- Assuming an integration user gives your product its own budget, when the pool is the org's aggregate.
- Using Composite Batch where Composite or sObject Collections would count as one call.
- Writing one record per call on a write-back path that runs all day.
- Retrying a 403 REQUEST_LIMIT_EXCEEDED in a tight loop, which spends nothing but delays every other tool in the org once the block lifts.
- Long-running SOQL queries that hold one of the org's 25 long-request slots.
- Calling a retired API version. Versions 21.0 to 30.0 were retired in Summer '25 and return 410, per the REST API End-of-Life Policy, and 31.0 to 40.0 are "deprecated and unsupported from Summer '27."
Frequently Asked Questions
What is the Salesforce API limit per day?
Enterprise orgs get 100,000 requests per rolling 24 hours plus 1,000 per Salesforce license. Unlimited and Performance get 5,000 per license. Developer Edition gets 15,000. A full sandbox gets 5,000,000.
Do managed package API calls count against Salesforce API limits?
Yes. Salesforce states that API calls made from installed managed packages count against the customer org's limit. Logic the package runs inside the org in Apex uses governor limits instead of the daily API pool.
Is the Salesforce API limit per user?
No. It's the aggregate of every API call to the org in a rolling 24 hours, so a dedicated integration user shares the same pool as every other tool.
How do I check Salesforce API usage from my integration?
Read the Sforce-Limit-Info header on any REST response, or call the /limits resource and check DailyApiRequests Max and Remaining.
Can Appnigma build our Salesforce integration so it stays inside customers' API limits?
Appnigma's done for you delivery builds and maintains customer-facing Salesforce integrations with a named integration engineer, and marketplace apps covers the native app when the work should run inside Salesforce.
Related Articles
- Salesforce Composite and GraphQL API
- Salesforce Bulk API 2.0 Guide
- Platform Events vs Change Data Capture in Salesforce
- Governor Limits in Verified Managed Packages
- What a Native Salesforce App Is
- HubSpot API Rate Limits Guide
Sources
- Salesforce Developers, Salesforce Developer Limits and Allocations Quick Reference, API Request Limits and Allocations
- Salesforce Developers blog, API Limits and Monitoring Your API Usage
- Salesforce Developers, REST API Developer Guide, Limit Info Header
- Salesforce Developers, REST API Developer Guide, List Org Limits
- Salesforce Developers, REST API Developer Guide, Supported Editions and Required Permissions
- Salesforce Developers, REST API Developer Guide, Composite
- Salesforce Developers, REST API Developer Guide, Composite Batch
- Salesforce Developers, REST API Developer Guide, sObject Collections
- Salesforce Developers, Salesforce Developer Limits and Allocations Quick Reference, Bulk API and Bulk API 2.0 Limits
- Salesforce Developers, Salesforce Developer Limits and Allocations Quick Reference, Connect REST API Limits
- Salesforce Developers, GraphQL API Developer Guide, API Request Limits
- Salesforce Developers, Platform Events Developer Guide, Default Platform Event Allocations
- Salesforce Developers, Apex Developer Guide, Execution Governors and Limits
- Salesforce Developers, Object Reference, API Total Usage Event Type
- Salesforce Developers, REST API Developer Guide, REST API End-of-Life Policy
