Salesforce API limits: what REQUEST_LIMIT_EXCEEDED means and how to catch it early

Failure facts checked on the vendor’s docs on Nov 8, 2026.

Salesforce APIs fail for a reason that has nothing to do with your code: the whole org shares one budget. A nightly sync, a partner app, a marketing tool and your own service all draw from it. When it runs out, every one of them gets the same error at the same time.

Three limits, one error code

Salesforce lists three kinds of API limit: concurrent requests, timeouts and the total allocation per 24-hour period.

• Concurrent. Counts requests that run for 20 seconds or longer. Production orgs and sandboxes allow 25 at once and Developer Edition and trial orgs allow 5. Shorter requests are not capped by this rule. Going over returns REQUEST_LIMIT_EXCEEDED.
• Timeout. REST and SOAP calls time out after 10 minutes, except queries, which follow SOQL limits.
• Total allocation. Calls per 24-hour period, per org.

Salesforce's error reference describes REQUEST_LIMIT_EXCEEDED as exceeding either the concurrent request limit or the request rate limit. On REST it appears as an HTTP 403, and the docs say that when a 403 carries this code you exceeded API request limits in your org. A 403 normally means a permissions problem, so a handler that treats every 403 as an auth failure will chase the wrong cause.

The daily allocation

Totals depend on edition. Developer Edition gets 15,000 calls per 24 hours. Enterprise and Professional Editions with API access get 100,000 plus a per-license amount (for example 1,000 per Salesforce license) plus any purchased add-ons. Unlimited and Performance Editions use 100,000 plus their own per-license amounts. A Full sandbox gets 5,000,000 by default.

Details that decide whether you hit it:

• Aggregate, not per user. The limit is enforced against everything calling the org. Calls from installed managed packages count.
• Many APIs count. REST, SOAP, Bulk API, Bulk API 2.0 and most Connect REST APIs. Calls from certain Salesforce connected apps, such as the mobile app, do not.
• Debug calls are separate. Calls with a DebuggingHeader have their own 1,000 per 24 hours and can continue after the org's total is reached.
• A soft edge, then a hard cap. Salesforce says it may let operations go past the limit by some amount, if possible, but a hard cap exists. Do not plan around the soft edge.
• You may not reach the number. Salesforce notes that load and performance issues can keep you from using the full allocation.

The docs state the allocation per 24-hour period and do not give a clock time for a reset, so judge headroom from usage over time, not from the time of day.

Where Salesforce shows usage

1. Sforce-Limit-Info header. On each REST response, apart from the versions endpoint. Example: Sforce-Limit-Info: api-usage=10018/100000; api-bursts=1/750. The first number is calls used and the second is the org's limit.
2. /limits resource. GET /services/data/vXX.X/limits/ lists the maximum and remaining value for each limit, including DailyApiRequests. It is available from version 29.0 to users with View Setup and Configuration, and its tabulated values are accurate to within five minutes.
3. Setup. The API Usage section of System Overview, and the API Request Limit per Month entitlement on the Company Information page.
4. API Usage Notifications. An email to a chosen user when usage passes a percentage of the allocation.

The header is the cheapest source, because it is free on every call you already make.

import json, re, time
import requests

def sf_call(instance, token, path, attempt=1):
    t0 = time.time()
    r = requests.get(f"{instance}/services/data/v60.0/{path}",
                     headers={"Authorization": f"Bearer {token}"}, timeout=30)
    used = limit = None
    m = re.search(r"api-usage=(\d+)/(\d+)", r.headers.get("Sforce-Limit-Info", ""))
    if m:
        used, limit = int(m.group(1)), int(m.group(2))
    error_code = None
    if r.status_code >= 400:
        try:
            error_code = r.json()[0].get("errorCode")
        except Exception:
            pass
    print(json.dumps({"msg": "vendor call", "vendor": "salesforce", "path": path,
        "status": r.status_code, "error_code": error_code, "attempt": attempt,
        "api_used": used, "api_limit": limit,
        "duration_ms": int((time.time() - t0) * 1000)}))
    return r

What to alert on

• api_used / api_limit crossing set levels. The percentage on its own is too coarse: compare it with the time of day, because 60% by early afternoon is a different problem from 60% by midnight.
• Any 403 with error_code of REQUEST_LIMIT_EXCEEDED. Count it apart from permission 403s.
• Usage by caller. The header shows only the org total, so tag each of your services in your own logs and add up calls per service.
• Concurrency of long requests. If you run big queries or parallel jobs, track how many are in flight at once against 25.
• The slope of api_used after a deploy or a new integration.

Example: a new sync that used the budget

This is an example, not output from a real project. A made-up crm-mirror job starts polling every 5 seconds after a release.

09:00:12Z msg="vendor call" vendor=salesforce caller=crm-mirror status=200 api_used=31200 api_limit=115000
13:30:41Z msg="vendor call" vendor=salesforce caller=crm-mirror status=200 api_used=96800 api_limit=115000
17:05:09Z msg="vendor call" vendor=salesforce caller=billing-export status=403 error_code=REQUEST_LIMIT_EXCEEDED api_used=115000 api_limit=115000

The failing caller, billing-export, did nothing different. The org total was used up earlier by crm-mirror, so the 403 shows up in an unrelated service. Moving the mirror to change events or batching its reads fixes the cause, and a higher allocation only delays it.

Checklist

1. Log Sforce-Limit-Info usage and the errorCode on every call.
2. Name the caller on every line, so you can split org usage by service.
3. Handle 403 REQUEST_LIMIT_EXCEEDED separately from permission errors.
4. Set API Usage Notifications as a second line of defense.
5. Batch work and avoid polling where a push alternative exists.
6. Keep long-running requests under 25 at once.

Related: monitoring third-party dependencies, capacity risks and vendor degradation. Sazabi can watch these logs once you send them.