Read the Limits resource
The REST Limits resource is available at the org’s versioned REST endpoint:
The response reports maximum allocation and remaining allocation for supported limits. Salesforce notes that the values can be accurate within five minutes of consumption and that rapid concurrent requests should be avoided when consistent readings matter. The API user also needs the documented setup permission to access the resource.
Do not poll `/limits` on every record. Cache the reading for a short operational interval and combine it with your own request ledger. A monitoring request should not become another noisy consumer.
GET https://yourDomain.my.salesforce.com/services/data/v66.0/limits/
Authorization: Bearer ACCESS_TOKEN
DailyApiRequests is only one line
The response can include `DailyApiRequests`, but Salesforce also exposes separate limits for Bulk API batches, Bulk API 2.0 query jobs, analytics, events, email, and other services. Identify the limit family that matches your workload. A REST integration can have remaining daily requests while a Bulk query allocation or event delivery allocation is the actual bottleneck.
Create a metric with org ID, environment, API version, limit name, maximum, remaining, observed time, and source. Never aggregate production and sandbox usage into one chart; their allocations and traffic patterns are different.
Build a useful budget model
Count requests by business outcome, not only by endpoint. One customer sync might use a list request, several detail reads, a metadata call, a write, and a verification read. A retry can double the cost of a failed operation. A dashboard that refreshes every few seconds may consume more capacity than the nightly job everyone watches.
For each workflow, record:
Multiply the expected calls by the schedule, then add headroom for interactive work and incidents. Treat the result as a planning estimate, not a promise of Salesforce allocation.
- scheduled runs and expected record count;
- list pages and detail calls per record;
- writes, retries, and post-write reads;
- concurrent workers and tenants;
- Bulk jobs and query jobs;
- third-party connectors sharing the org.
Alert before exhaustion
Create warning levels such as 30%, 15%, and 5% remaining, but tune them to the time left in the allocation period and the organization’s recovery process. A 10% remainder at the start of a busy window is more serious than the same value near reset. Alert on rate of consumption as well as remaining capacity.
An alert should name the org, limit family, remaining value, top workflows, current queue, and recommended action. “Salesforce API limit low” is not enough for an operator to decide which job to pause.
Use a rolling consumption view as well. Store periodic readings with the number of requests your own gateway observed between readings, then compare the two signals. The values will not match perfectly because other clients may share the org and Salesforce reports usage with a documented delay, but the comparison can reveal an unregistered connector. Review sudden changes in calls per successful record, not just total volume.
Protect interactive work
Separate low-priority backfills from customer-facing updates. Give the queue a per-org budget and reserve capacity for latency-sensitive requests. Stop starting new backfill pages when the remaining estimate crosses the pause threshold. Persist a checkpoint so the job resumes from a known boundary.
Do not increase concurrency to finish before the limit disappears. More workers can consume the remaining allocation faster and create synchronized retries. Use bounded concurrency, exponential backoff for transient errors, and a maximum retry count.
Reduce avoidable requests
Cache stable metadata, request only needed fields, use composite or bulkified patterns where appropriate, and avoid fetching the same record after every write when the response already contains the needed result. Coalesce repeated updates for one record. Replace full scans with change capture or a durable high-water mark when the business process permits it.
Measure before and after each optimization. A lower request count is not a success if it drops records, skips fields, or creates duplicates. Track successful records, failed rows, latency, queue age, and reconciliation differences alongside request volume.
Incident procedure
When usage rises unexpectedly, preserve a Limits response, identify the top consumers, pause backfills and aggressive polling, and inspect retry loops. Confirm whether the failure is `REQUEST_LIMIT_EXCEEDED`, a Bulk-specific limit, a permission issue, or a server error. Do not rotate OAuth credentials expecting an org allocation to reset.
After capacity returns, resume from checkpoints and reconcile records changed during the pause. Replay only idempotent operations. Document the request spike, affected workflows, number of delayed records, and permanent reduction made afterward.
For a scheduled integration, make the pause visible in its run state: `running`, `paused_for_capacity`, `waiting_for_review`, or `completed`. This prevents an operator from starting a second copy because the first job appears silent. A durable state record should include the last source checkpoint, the org, the limit family, and the reason for the pause.
QA checklist
Test that the integration can read `/limits` with the intended API user, handles permission failure, stores timestamps, distinguishes limit families, pauses a queue at the configured threshold, resumes from a checkpoint, and does not retry a deterministic limit error without a policy. Test production and sandbox separately.
At the end of each incident, compare the planned request model with observed traffic. Record which workflow caused the variance, whether retries or verification reads were included, and which change will reduce future usage. This turns a one-time quota warning into an actionable capacity baseline for the next release.
The trap: treating `DailyApiRequests` as a universal Salesforce quota. Bulk jobs, queries, events, and other services have separate allocations.
Turn the limit into a queue decision
Define what happens at each threshold: continue normal work, slow backfills, pause new pages, or stop all nonessential jobs. Store that state with the org and limit family. When capacity returns, resume from the saved checkpoint and reconcile the boundary rather than restarting from page one. This makes the monitoring data operational instead of leaving it as a dashboard that nobody acts on.
Where these facts come from