Apex callouts share the org with every other tenant. To keep one chatty integration from starving everyone else, the platform enforces hard ceilings on count, time, and size.
The numbers to memorise
| Limit | Value |
|---|---|
| Callouts per transaction | 100 |
| Total callout time per transaction | 120 seconds (cumulative across all callouts) |
| Single callout timeout (max) | 120 seconds (default 10, set via req.setTimeout()) |
| Request body size (sync) | 6 MB |
| Response body size (sync) | 6 MB |
| Request/response body (async) | 12 MB |
| Maximum HTTP header size | 32 KB total |
| Default chunked transfer | Automatic for > 1 MB |
What counts as “a callout”
Each Http.send() or generated SOAP method invocation. Calling the same endpoint 50 times in a loop is 50 callouts.
Synchronous vs asynchronous
The 6 MB ceiling is the synchronous Apex heap limit applied to the response. In async contexts — @future, Queueable, Batch — the heap is bigger (12 MB), so callouts can handle bigger payloads. That’s one of the better reasons to push integration code into async.
Order-of-operations rules (not limits, but bite the same)
- No callouts after DML in the same transaction. Reorder the work so callouts happen first, or push the callout to
@future(callout=true)/ Queueable. - No callouts from triggers synchronously. Triggers fire mid-transaction; enqueue async work instead.
@future(callout=true)annotation required for@futuremethods that call out — the platform won’t let you sneak one in.
How to actually live within these limits
Batch your requests. If the API supports bulk endpoints (e.g. /accounts/bulk taking 100 IDs), use them. One callout for 100 records beats 100 callouts.
Compress requests. req.setCompressed(true) enables gzip on the request body. Modern APIs accept it; you can fit much more in 6 MB compressed.
Use a real timeout. The 10-second default is wrong for almost every real API. Set req.setTimeout(60000) for slow systems; cap at 120 seconds.
Split big work across transactions. Hit the 6 MB response limit? Page through the API: 200 records per call, multiple async jobs each making one call.
Monitor with Limits.getCallouts() and Limits.getLimitCallouts() in long-running code, especially in Batch Apex where the execute() context resets the count per chunk.
Common interview follow-ups
- Can you increase the 100-callouts limit? — No. Refactor or move work across transactions.
- Why does the platform block callouts after DML? — A callout takes seconds, during which row locks would stay held, blocking other users. The “DML then callout” order is reversed to “callout then DML.”
- Do callouts to Salesforce APIs from Apex count? — Yes, even Salesforce-to-Salesforce hits the same callout limit.
Verified against: Apex Developer Guide — Execution Governors and Limits. Last reviewed 2026-05-17 for Spring ‘26 release.