Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The answer, briefly: the daily API request limit is calculated from your edition and licence count, it resets on a rolling 24-hour window rather than at midnight, and the first warning most orgs get is an integration failing. Checking it takes one query and should be on a schedule, not in someone’s memory.

Reading your current usage

The cheapest check is the Limits REST endpoint, which does not itself consume a meaningful amount:

sf org list limits --target-org production

The rows that matter are DailyApiRequests, DailyBulkApiBatches, DataStorageMB and FileStorageMB. Each shows remaining against maximum, and remaining is the number to watch because the maximum changes when licences change.

In Apex, OrgLimits.getMap() gives the same data, which is what you want for a scheduled job that posts a warning somewhere people read.

The rolling window

The 24-hour window rolls continuously. It does not reset at midnight in your time zone or anyone else’s. A batch job that consumed 80% of the allowance at 3am yesterday is still counted against you at 2am today, and the allowance returns gradually rather than all at once.

The practical consequence: an org that hits the limit does not recover at midnight. It recovers slowly through the following day, and a retry loop hammering the API keeps it there.

What counts and what does not

Counted:

  • Every REST and SOAP API call, including one that returns an error
  • Every Bulk API batch, counted as one call per batch rather than per record, which is the whole reason Bulk API exists
  • Callouts into Salesforce from middleware, from a portal, from a mobile app you built
  • The Metadata API, including every deployment

Not counted:

  • Apex callouts going out to other systems
  • The Lightning UI itself, and Lightning Data Service
  • Most Bulk API 2.0 query operations, which have their own separate allowance

That last distinction matters when sizing a migration. A Bulk API 2.0 load of two million records is a handful of API calls, and the same work through the REST API at 200 records per call is ten thousand.

Finding what is consuming it

Setup, then API Usage Notifications, will email you at a threshold. That tells you it is happening and not who is doing it.

For the who, query the API usage by client:

SELECT Client, Count
FROM ApiEvent
WHERE CreatedDate = LAST_N_DAYS:1
GROUP BY Client
ORDER BY Count DESC

This needs Event Monitoring. Without it, the practical alternatives are the Login History page filtered by application, and asking each integration owner what they changed. Neither is good, which is an argument for Event Monitoring in any org with more than two integrations.

The three causes, in order of frequency

1. A polling integration with the interval set too low. Something checking for new records every thirty seconds, running all night, finding nothing. Move it to a platform event or Change Data Capture and the polling disappears entirely.

2. Row-by-row processing. A middleware job that reads one record, updates one record, in a loop. The fix is the same as bulkification in Apex: batch the calls.

3. A retry loop with no ceiling. Something failing and retrying immediately, forever. This is how an org goes from comfortable to locked out in an afternoon, and the fix is in retry design.

Raising the limit

You can buy additional API capacity, and Salesforce will sometimes grant a temporary increase for a migration if you ask in advance with a reason. Neither is a substitute for fixing a polling loop, and support will usually say so.

Set the alarm below the cliff

Configure the notification threshold at 60% rather than 90%. At 90% you have hours to react. At 60% you have days, and the difference is whether the fix is considered or panicked. Put the alert somewhere a person sees, not into an inbox rule.

Frequently asked

Does a failed API call count? Yes. A malformed request consumes the same as a successful one, which is why a broken integration can exhaust an allowance faster than a working one.

Do sandboxes share the limit? No, each org has its own. Sandbox limits are generally generous, which is why load testing in a sandbox tells you little about production consumption.

What happens at the limit? Requests fail with REQUEST_LIMIT_EXCEEDED. The UI keeps working, so the org looks fine while every integration is down.