Understanding how Salesforce API calls share limits across all integrations and what that means for Apex callouts

Shared API limits in Apex callouts are one of those topics that sneak up on you in real projects. You think you’re just wiring two systems together, and suddenly you’re staring at a limit that feels bigger than the problem you were trying to solve. If you’re exploring topics around the Certified Integration Architect Designer exam, this is one of those fundamentals you want to get right—from both a functional and a routing-your-traffic standpoint. Let me walk you through what the API limit really means when multiple integrations are buzzing at the same time—and why the answer to a common quiz question is more than just a trivia fact.

What the question is really asking about

Here’s the thing: when Salesforce talk about API limits, they’re not talking about a personal cap that only applies to one integration, one app, or one user. The limit is pooled. In practical terms, the total number of API calls made in your Salesforce org—whether they come from a third-party application, a custom integration, or a user clicking around in the UI—counts toward the same shared bucket. So the correct statement in a typical multiple-choice question is: API limits are shared with all integrations.

If you remember one sentence about this topic, that’s the sentence to keep: the limits are a collective resource in the org, not a per-app or per-connector cap.

Why shared limits matter in real-world design

This isn’t just trivia. It changes how you design, monitor, and govern integrations.

• Resource contention: When several integrations are active, they’re competing for the same pool. One aggressive integration can push a lot of calls through in a short window, leaving others stranded. The result isn’t just a failure in one connection—it can cascade, slowing down or breaking processes that other teams depend on.

• Visibility and accountability: If you can’t see who’s using how much, you won’t be able to balance load or plan capacity. Visibility helps you answer practical questions like: which integration is peak during lunch hours? Do we have a routine batch that spikes API usage at 2 a.m.?

• Design choices matter: The shared nature encourages smarter patterns—batching, caching, deduping calls, and using more efficient APIs when possible. It also nudges you toward asynchronous patterns where appropriate, so you’re not waiting on real-time round-trips for everything.

• Incident response becomes collaborative: Since the resource is shared, a spike in one area can impact others. A healthy approach is to set up alerts and cross-team coordination so the moment you see usage climbing, you can throttle, re-route, or optimize without treating it as a one-team problem.

Daily reset reality versus the fear of the unknown

A common confusion you’ll encounter in exams or real life is whether limits reset every 24 hours. Yes, they do reset on a rolling 24-hour schedule, which gives us a predictable cadence. But here’s the nuance that trips people up: just because they reset daily doesn’t mean you get a free pass for the next day. The pool you’re working from includes all API calls made in the org, across all apps and users, during that rolling window. If you’re carrying a heavy load at the moment of reset, you’ll start the new window with a fresh pool—but you also start fresh next to a backlog of calls that might still be in progress or queued as your systems catch up.

And about the “emergency” myth you might hear: there isn’t an automatic, magic exception that allows you to exceed the pool during a crisis. If you need more throughput in emergencies, you’d typically implement design strategies (like offloading to asynchronous processes, scaling through bulk APIs, or queueing with platforms events) and rely on architectural changes rather than counting on exceptions to the limit.

Practical ways to keep API usage healthy

If you’re designing solutions in a multi-integration environment, these moves help keep you out of the red zone.

• Monitor in real time: Use Salesforce’s built-in dashboards (Setup > System Overview) and, when you can, more detailed telemetry (like Event Monitoring or your existing SIEM/observability stack). You want to see not just the total count, but patterns—what hour, what integration, what type of call. Early visibility is cheaper than firefighting.

• Use the right tool for the job: If you’re sending large volumes or back-and-forth data, consider Bulk API for large data transfers or asynchronous patterns rather than synchronous, single-call interactions. This can dramatically reduce the number of API calls in peak moments.

• Reduce churn: Minimize unnecessary calls. Here are a few tactics:

• Cache data on the integrator side when appropriate, so you don’t fetch the same information repeatedly.

• Debounce or throttle calls from UI or automation that can tolerate a small delay.

• Compare data, and skip calls when nothing changed since the last fetch.

• Design for backpressure: If you anticipate high loads, build in retry and backoff logic, plus fallbacks. A graceful degradation beats a hard failure that triggers cascades across connected systems.

• Plan for peak hours: If you know a particular integration spikes at certain times (think nightly exports, end-of-day reconciliations, or promotional campaigns), design with these windows in mind. It could mean staggering jobs, using queues, or temporarily increasing the processing window.

• Document and align ownership: When multiple teams own different integrations, clear ownership helps you coordinate changes that affect the shared pool. A simple runbook with escalation steps can save confusion during a spike.

A few concrete tips you can put to work

• Leverage the Limits class in Apex: In your code, you can programmatically check what you have left in the pool for callouts and API calls. It’s a practical, real-time sense-check that helps you decide when to move to asynchronous paths or to throttle. The general idea is to leave a healthy buffer so you aren’t caught flat-footed when traffic climbs.

• Favor event-driven patterns where possible: Platform events and change data capture can reduce the need for constant polling across systems. When an external app only needs a signal when something happened (rather than a full call every time), you conserve API callouts and keep the pool healthier.

• Use cancellation and deduplication strategies: If two processes are about to perform the same update, a deduplication rule can prevent duplicative calls. This not only saves API calls but also reduces the risk of data conflicts and extra processing.

• Regularly review integration footprints: Set a cadence (monthly or quarterly) to review how many calls each integration is making. If a new integration is added or a current one is expanded, reassess the shared pool and adjust the design if necessary.

Common misconceptions worth clearing up

• The limit applies only to outbound calls: Not true. Both inbound and outbound calls count toward the shared pool. Your users plus external apps all drain the same resource.

• A spike means you’ve got “more” room during emergencies: The pool doesn’t automatically grow for emergencies. You’d need a deliberate architectural approach to handle spikes without tripping the limit.

• The limit resets per integration: In reality, it’s a pooled resource across the org. Treat every integration as part of a single traffic ecosystem.

• You can solve it with a one-time tweak in the code: It’s often a design problem, not just a patch. The most reliable fix tends to be combining better data patterns, smarter scheduling, and smarter use of Salesforce APIs.

Bringing it together: why this matters for the Certified Integration Architect Designer journey

If you’re exploring topics that frequently appear around this certification, you’ll notice a common thread: systems are interconnected, and limits aren’t just numbers on a screen—they’re strategic constraints that shape how you design, implement, and operate solutions. Understanding that API limits are shared across all integrations helps you think in terms of capacity planning, governance, and architecture that scales with your organization’s needs. It’s about building resilient systems that can absorb traffic, adapt when things surge, and keep critical workflows alive.

In practice, this means you’ll be more deliberate about where you place logic, how you structure data flows, and how you monitor performance over time. You’ll design with backpressure in mind, choose patterns that minimize API churn, and communicate with stakeholders about what “shared limits” imply for timelines and service levels. All of this feeds into a broader capability profile: you’re not just wiring systems; you’re shaping a robust integration ecosystem.

A closing thought

In the end, the one truth to hold onto is simple: API calls in Salesforce are a shared resource. Treat them as such, and you’ll avoid surprising outages, maintain smoother operations, and design smarter integration strategies. That mindset—layered with practical tooling, concrete patterns, and a dash of governance—will serve you well as you navigate the Certified Integration Architect Designer landscape. And if you ever find yourself in a moment of doubt about why a particular integration behaves the way it does, go back to that shared-pool idea. It’s the compass that keeps your integrations in harmony rather than turning into a footrace for scarce API time.