Speed Limits
Module 4 of 8 in the chapter Salesforce as an API Consumer, chapter 9 of the Integration Architect course. Each module stands on its own. Previous: Dealing With the Answer · Next: Where a Callout Can Run
The question this module answers: What limits does Salesforce put on callouts, and which one will surprise you in production?
Salesforce doesn’t like waiting for other systems. It’s a multitenant platform: every org shares the servers, so a transaction that sits and waits holds resources someone else could use. So you’re best with short and fast calls to an external system. And there are speed limits to keep you honest.
When you’re making callouts, you’ve got four things to watch: how big is my payload, how many individual calls, how long is a single call, and what’s the total across all the calls. These are your limits.
The Limits on One Transaction
Section titled “The Limits on One Transaction”Per transaction, on Winter ‘27 (Execution Governors and Limits (opens in a new tab) and Callout Limits and Limitations (opens in a new tab), Apex Developer Guide, checked 2026-10-31):
| Limit | Synchronous | Asynchronous |
|---|---|---|
| Callouts | 100 | 100 |
| One callout’s timeout | 10 seconds by default, up to 120 | the same |
| All callouts together | 120 seconds | 120 seconds |
| Heap: everything in memory, including the answer | 10 MB | 25 MB |
So you can make 100 one-second calls, or one 120-second call, but not both. Read the 120 seconds the right way: it’s what Salesforce allows, not what a person will put up with. If someone hits Save and waits two minutes, something’s wrong with the design. Kick the work to an asynchronous process and let them get on with their day (module 5).
The heap one bites hardest, because it doesn’t fail gently. A transaction that goes over the heap gets “an uncatchable System.LimitException error” (same page). Your try and catch from module 3 won’t save it. If an answer could be big, decide before you call: ask for less, page through it, or move the data another way.
And in a Developer Edition org, you can only have 20 callouts going out at the same time. It’s a limit you’ll meet in a lab, not in production.
The Red Transactions
Section titled “The Red Transactions”Now the one that waits for production.
Every org has a limit on long-running transactions: synchronous Apex that runs for more than 5 seconds. I call those red transactions. Each one, on its own, is allowed. But there’s a limit on how many can be red at the same time across the whole org. Today it’s set by your licences: one for every 100 licences, at least 10 and at most 50. Go over, and new ones are denied (same page).
Here’s why it surprises people. In development and testing, you never notice it. Two testers can’t make ten red transactions at once. I was consulting at one client where creating a field-service appointment was taking three to eight seconds. It worked just fine in development, in test, in QA. Then it went to production, with all the dispatchers making appointments at once, and random ones started being killed. They were exceeding the number of long-running transactions. When the next client needed appointments, I designed a whole different appointment check, because I knew this limit was waiting for us. It’ll get you when you least expect it, and only in production, which is the worst time.
The good news for callouts: the time spent waiting for a callout doesn’t count. Salesforce pauses the timer while it waits, and “HTTP callout processing time isn’t included when calculating this limit” (same page). That changed in Winter ‘20; before it, a slow callout could turn a transaction red. So what makes a transaction red today is slow work inside Salesforce: heavy triggers, complicated automation, big queries. In my story, it was the appointment work, not the waiting.
What turns a transaction red. Waiting on a callout doesn’t; slow work inside does.
Two Long-Running Limits, Not One
Section titled “Two Long-Running Limits, Not One”Don’t mix this up with the limit from chapter 8. That one is about calls coming in: no more than 25 inbound API calls of 20 seconds or more at once in production. This one is about Salesforce’s own Apex running more than 5 seconds, 10 to 50 at once by licences. Same idea, different doors, different numbers. Both punish slow work under load, and both only show up when the load is real.
Designing for the Limits
Section titled “Designing for the Limits”- Count before you build. For every callout: how big is the answer, how many calls per transaction, how long does each take, and how many happen at once at the peak? Chapter 6’s number of zeros gives you the peak.
- Set the timeout from the other system’s real speed, not the default, and decide what happens when it’s hit.
- Keep the transaction short around the callout. If the work before or after the call is slow, the transaction turns red whatever the call does.
- Test at production load. The red-transaction limit is invisible with two testers. A load test at the real number of users is the only way to see it before your users do.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- The four numbers for every callout: payload size, calls per transaction, time per call, and calls at once at the peak.
- Which callouts can make a person wait, and which go asynchronous.
- The biggest answer the heap must hold, with room to spare, and what happens if it’s bigger.
- The load test, at the real number of users, before go-live.
Explore
Section titled “Explore”- Execution Governors and Limits (opens in a new tab): Apex Developer Guide, every per-transaction and org-wide Apex limit (checked 2026-10-31)
- Callout Limits and Limitations (opens in a new tab): Apex Developer Guide (checked 2026-10-31)
- Who’s at the Door: chapter 8, the inbound long-call limit