⚡ Key Points: 1-Minute Summary
- The Shared Bucket: Inbound API calls draw from a single, rolling 24-hour org allocation. One greedy integration can crash the whole system.
- Dedicated Users: Give every integration its own API user. This allows you to track exactly who is burning the budget.
- Push > Poll: Never let external systems continuously ask "Is there anything new?". Push updates to them using Change Data Capture (CDC) or Platform Events.
- Batch the Chatty: Convert systems that write records one-at-a-time to use the Composite API or Bulk API.
- Proactive Alerts: Set API usage thresholds at 70% and 85%. Limits should be a known budget, not a surprise ceiling you hit during an incident.
๐ฌ In plain words: Your Salesforce API limit is a daily allowance shared by every single integration hooked into your org. If one system goes crazy, everything stops. The architect's job is to measure who spends what, force chatty integrations to use efficient Bulk or Composite APIs, cache reference data, and set up alerts before the budget hits zero.
๐ฌ Real-Life Example: The Monday Morning Outage
The Problem: At 9:00 AM on a Monday, every integration in the org failed at once. Nothing had been deployed. Support raised a case to buy more API calls, and the org limped through the week.
Why this is bad: It was never a capacity problem. A partner's polling script was asking Salesforce "anything new?" four times a second, all weekend, exhausting the 24-hour budget. Buying more API calls just moved the inevitable crash to a later Monday.
The Fix: The architect gave the partner a dedicated integration user to monitor their traffic. Then, they replaced the polling script with a CDC event subscription. API consumption dropped by 90%, the partner got fresher data instantly, and the org regained massive headroom.
The Problem: At 9:00 AM on a Monday, every integration in the org failed at once. Nothing had been deployed. Support raised a case to buy more API calls, and the org limped through the week.
Why this is bad: It was never a capacity problem. A partner's polling script was asking Salesforce "anything new?" four times a second, all weekend, exhausting the 24-hour budget. Buying more API calls just moved the inevitable crash to a later Monday.
The Fix: The architect gave the partner a dedicated integration user to monitor their traffic. Then, they replaced the polling script with a CDC event subscription. API consumption dropped by 90%, the partner got fresher data instantly, and the org regained massive headroom.
๐ง Core Takeaway: Treat API limits as a daily financial budget. Measure the spenders, batch the chatty ones, cache the static data, and sound the alarm long before the bucket is empty.
๐️ The Core Concept: Budget, Don't Discover
Inbound API calls in Salesforce are governed by a rolling 24-hour org allocation. This allocation scales based on your Salesforce edition and user licenses. However, it is a shared bucket. If Marketing Automation decides to sync a million leads inefficiently, the ERP integration might fail to create new orders.
Note that several API types have entirely separate buckets and do not consume this primary allocation. These include:
- Bulk API jobs and records.
- Concurrent long-running requests.
- Hourly OData callouts (Salesforce Connect).
- Event delivery allocations (Platform Events/CDC).
๐งญ 360 Card — API Limits Strategy
Rule: API capacity is a budget with named owners. Push data out instead of letting external systems poll for changes.
Gain: By using one integration user per consumer, you gain visibility. You can see who spends what and shut off a rogue integration without breaking the rest of the business.
Price: The budget is shared and rolling. One badly behaved consumer will take down every other integration with it if left unchecked.
Mirror (Buying more calls): Buying limits works immediately. It is a painkiller, not a cure. The inefficient polling continues, just at a higher cost.
At volume: Replacing a polling mechanism with a push mechanism (events) is the single biggest saver. One event subscription replaces 10,000 "anything new?" calls.
Rule: API capacity is a budget with named owners. Push data out instead of letting external systems poll for changes.
Gain: By using one integration user per consumer, you gain visibility. You can see who spends what and shut off a rogue integration without breaking the rest of the business.
Price: The budget is shared and rolling. One badly behaved consumer will take down every other integration with it if left unchecked.
Mirror (Buying more calls): Buying limits works immediately. It is a painkiller, not a cure. The inefficient polling continues, just at a higher cost.
At volume: Replacing a polling mechanism with a push mechanism (events) is the single biggest saver. One event subscription replaces 10,000 "anything new?" calls.
๐ฌ Core Q&A: Defending Your Limits
Q: How do you architect an org's API budget across five different integrations?
๐ฏ Say this first: "Measure each integration's consumption. Convert chatty ones to Bulk or Composite APIs. Cache reference data outside of Salesforce. Reserve headroom, and alert at thresholds before hitting the wall."
A: Follow these four moves:
- Isolate: Give each integration its own dedicated integration user. That buys you attribution, per-consumer measurement, and the ability to surgically revoke access if one goes rogue.
- Budget: Forecast the daily consumption per consumer, sum it against the org limit, and maintain a strict 30% headroom buffer.
- Optimize: Push chatty integrations down the efficiency ladder. Replace polling with CDC or Platform Events (often a 10x-100x reduction in calls). Convert record-at-a-time REST calls into the Composite API. Move massive data loads to the Bulk API.
- Defend: Monitor usage with Event Monitoring and API Usage reports. Set active alerts at 70% and 85%. Crucially, document a "shed order"—a pre-approved plan of which non-critical integration gets paused first during a limit crunch.
๐ Scenario-Based Follow-Ups
Q: It's 2:00 PM and you're at 95% of your daily API calls. What are your immediate and structural responses?
A: You must split your response into immediate triage and structural fixes.
- Immediate: Identify the offending consumer by reviewing API usage per integration user. Pause or throttle the non-critical integration to save the remaining 5% for mission-critical operations. Do not rely on Salesforce's slight over-limit tolerance.
- Structural: Once the fire is out, convert the offender from polling to event-driven architectures. Batch their writes using Composite or Bulk APIs. Require them to cache static reference data client-side. Only consider buying extra API capacity after you have proven the architecture is as efficient as possible. Paying to subsidize a wasteful polling loop is bad architecture.
Q: A vendor's managed package polls every 30 seconds and you cannot change its source code. What are your containment options?
A: If you can't fix the code, contain it at the boundary you control.
- Run the package under a dedicated integration user so you can actively isolate and measure its exact API burn rate.
- Negotiate the configuration. Most enterprise vendors expose a configurable polling interval in custom settings. Change it from 30 seconds to 5 minutes.
- Check if the package supports modern webhooks or streaming API modes instead of polling.
- Escalate to the vendor armed with hard data from your Event Monitoring logs. Put exact financial numbers on the API burn.
- If all else fails, document the standing consumption as a fixed cost in your API budget, size your headroom around it, and make API efficiency a strict requirement in your next software procurement cycle.
Q: A partner system is hammering you with single-record REST API calls. What do you do?
A: In the short term, rate-limit them at the API gateway layer (like MuleSoft) or through their application's policies to protect Salesforce. The long-term fix is negotiating a better API contract. Force them to use a Bulk or Composite endpoint for writes, and an event subscription (CDC or Platform Events) for reads. This means one conversation replaces 10,000 single-record calls. API design is a negotiation, and the architect must dictate the terms of engagement.