Sandbox testing hides API limit risk because most sandboxes never carry the record volume, integration traffic, or concurrent user load that production handles every day. A callout that runs clean against 200 test records can blow through a daily limit the moment it hits two million real ones. Teams usually find this out during a release weekend, not during QA, which is exactly backward.
Salesforce API limits testing sounds like a checkbox exercise. It is not. Governor limits, daily API request caps, and callout timeouts are all tied to scale, and sandboxes are structurally built to avoid scale. That mismatch is the whole problem, and it is fixable once you name it correctly.
Why Sandbox API Behavior Diverges From Production
Full copy sandboxes mirror schema and configuration well. They do a poor job mirroring load. Fewer active users means fewer concurrent API sessions. Smaller data volumes mean SOQL queries return rows in the hundreds instead of the hundreds of thousands. Integration middleware often points at a mock endpoint or gets throttled deliberately during testing, so the callout patterns that hammer production simply do not exist in staging.
Edition and purchased add-ons matter too. Daily API request limits scale with user licenses and specific add-on purchases, and sandbox orgs frequently run with a different license mix than production. A sandbox might have generous headroom relative to its own tiny footprint while production sits close to its ceiling every afternoon. Nobody notices the gap until a batch job or an AI agent starts making thousands of calls in a tight window.
Partial copy and dev sandboxes make this worse. They carry a fraction of production's object relationships, so any query with nested subqueries or cross-object joins behaves like a toy version of the real thing. Test it there and you have tested almost nothing about how the query performs at scale.
The Governor Limits Sandbox Testing Never Trips
Governor limits exist per transaction, not per org, which is exactly why small sandboxes hide them. A transaction that queries 500 rows never comes close to the 50,000 row SOQL limit. Run the same logic against a case object with three million records and a poorly filtered query, and you hit the wall fast.
| Limit type | Typical sandbox behavior | Production risk |
|---|---|---|
| SOQL query rows (50,000 per transaction) | Rarely approached with small data sets | Hit during bulk case merges or nightly sync jobs |
| Bulk API batch limits | Tested with a handful of batches | Thousands of batches queue during month-end data loads |
| Callout timeout (120 seconds) | Mock endpoints respond instantly | Real third-party APIs slow down under production load |
| Daily API request limit | Sandbox usage is a fraction of daily allocation | Integrations and AI agents can exhaust the daily cap by early afternoon |
| Platform event daily limits | Low event volume during manual testing | High-frequency automation triggers events far faster than expected |
None of these limits are hidden or undocumented. Salesforce publishes them clearly. The problem is not visibility, it is exercise. You cannot know whether a limit will bite until you generate enough real activity to press against it, and most sandboxes are built specifically to avoid generating that activity.
Where This Breaks: Agentforce and Integration Callouts
Agentforce agents make this risk sharper, not smaller. An agent resolving a case might query related orders, run a knowledge search, and fire a callout to an external inventory system, all inside one conversational turn. Test that flow against a sandbox with 50 sample records and it looks instant. Run it against a production case object with millions of rows and several years of history, and the same logic can chew through query rows and API calls fast enough to throttle other transactions on the same org.
Integration middleware tells a similar story. Polling jobs that check for record changes every five minutes look harmless in a sandbox with a dozen test accounts. Point that same polling interval at production with 50,000 active accounts updating throughout the day, and you can burn through a meaningful share of the daily API allocation before lunch. I have seen teams discover this only after a second, unrelated integration started failing with limit errors that had nothing to do with its own code.
The frustrating part is that none of this is exotic. It is arithmetic. Multiply a per-record cost by a realistic record count and compare it to the published limit. Most teams skip that math because their sandbox never gives them a realistic record count to multiply against.
Testing API Limits the Right Way
Fixing this starts with data, not code. You need sandbox data that resembles production in volume and distribution, not just in schema. This is where a tool like SproutEzee earns its keep: it generates production-like data volume inside a sandbox so queries, batch jobs, and callouts actually get exercised at realistic scale before release, instead of getting rubber-stamped against a handful of sample records.
Once the data volume is realistic, the test itself gets simpler. Run the actual integration jobs, not simplified versions. Fire the actual Agentforce conversation flows against a full data set. Load test batch Apex with record counts that match a normal production day, not a demo day. If a limit is going to break, it should break in a sandbox with your team watching, not in production with a customer on the phone.
Gate this testing inside the deployment pipeline itself. DeployEzee can hold a release until API limit and load tests pass, which turns limit testing from an optional step someone forgets under deadline pressure into a condition the pipeline actually enforces. That single change fixes more incidents than any amount of documentation ever will.
Salesforce API Limits Testing: A Practical Checklist
Every org's limit profile is different, but the checklist that catches most problems is short and repeatable.
- Refresh sandbox data volume to within 70-100% of production record counts before any integration or Agentforce test cycle.
- Run bulk jobs with production-scale batch sizes, not the default test batch of 10 or 50 records.
- Replace mock callout endpoints with rate-limited test endpoints that mimic real third-party latency.
- Track cumulative daily API calls across all integrations during a test cycle, not just per-job counts.
- Test concurrent execution, since limits like concurrent Apex requests only surface when multiple jobs run at once.
Most teams do the first item and skip the rest, which explains why concurrency-related limit errors are so common in production despite passing every individual test in isolation. Limits interact. Testing them one at a time misses that entirely.
What to Monitor After You Ship
Testing reduces risk, it does not eliminate it. Production traffic patterns shift, new integrations get added, and an Agentforce use case that started small can scale up in usage within weeks. Ongoing monitoring is the second half of this problem, not an afterthought.
Salesforce's API usage dashboard under Setup gives a real-time view of daily consumption against the org's limit, and it is worth checking weekly rather than only when something breaks. Event Monitoring, where licensed, adds visibility into which integration user or connected app is driving the heaviest usage, which turns a vague limit error into a specific, fixable target.
Set alert thresholds at 70% and 90% of the daily API limit rather than waiting for the hard failure at 100%. A warning at 70% gives a team days to investigate; a failure at 100% gives them an outage. The gap between those two outcomes is entirely a matter of whether anyone was watching before the ceiling hit.
Frequently Asked Questions
Why does sandbox testing miss real API limit problems?
Sandboxes typically hold far less data and far less integration traffic than production, so queries and callouts never reach the volume needed to trip governor limits or daily API caps. A job that looks fine against a few hundred records can behave very differently against millions. The limit itself does not change, but the conditions needed to reach it only exist in production.
What is the Salesforce daily API request limit based on?
The daily API request limit is tied to the org's edition, the number of licensed users, and any purchased API add-ons. Sandboxes often run with a different license mix than production, which means their available headroom does not reflect what production actually has to work with. This makes sandbox usage a poor predictor of real-world consumption.
How does Agentforce affect API limit risk?
Agentforce agents can trigger multiple queries, knowledge searches, and external callouts within a single conversational turn, which multiplies API and governor limit usage quickly at scale. Testing these flows against small sandbox data sets hides that cost because the queries never touch enough records to matter. Testing against production-scale data before launch is the only reliable way to see the real usage pattern.
What is the best way to test API limits before a release?
Refresh sandbox data to a volume close to production, run integration and batch jobs at realistic scale, and track cumulative daily API usage across every job rather than testing each one in isolation. Tools that generate production-like data volume in a sandbox, such as SproutEzee, make this practical without exposing real customer data. Gating releases on these tests inside a CI/CD pipeline ensures the check actually happens instead of getting skipped under deadline pressure.
How can teams monitor API limit usage after going live?
Salesforce's built-in API usage dashboard under Setup shows real-time consumption against the daily limit and should be checked on a regular schedule, not just after an incident. Event Monitoring, where available, identifies which specific integration or connected app is driving usage. Setting alert thresholds at 70% and 90% of the limit gives teams time to react before a hard failure disrupts users.