When do Salesforce API limits reset, and why isn't waiting until then a real fix?

The 24-hour counter resets at 00:00 Pacific Time (UTC-8 standard, UTC-7 during US daylight saving). Integrations that failed with REQUEST_LIMIT_EXCEEDED resume automatically at the reset — but if the underlying consumption pattern hasn't changed, you'll hit the same wall again the next day, usually at the same time. The reset is a clock, not a fix. Use the reset window to confirm root cause (which apps consumed the most calls before reset?) but treat anything you ship as a temporary patch until you've throttled the offender. If you're hitting the wall before 3pm Pacific consistently, you're consuming faster than the day-rate allocation supports — even another 24 hours won't help.

How many API calls does my Salesforce org actually get?

The formula is edition baseline + (1,000 × full Salesforce user licenses), capped at an edition-specific maximum. Enterprise Edition: 100,000 base, capped at 1.5M. Unlimited Edition: 1,000,000 base, capped at 5M. Professional Edition customers get a flat 1,000 calls/day with no per-user scaling. Salesforce Functions, OmniStudio runtime calls, and external services may consume from a shared pool depending on your contract — check the Limits page in Setup or run a SOQL query against OrganizationLimits.DailyApiRequests via the Tooling API for the authoritative number.

Does Bulk API 2.0 count against the same limit as REST?

No. The Daily API Request Limit covers REST and SOAP calls; Bulk API 2.0 has its own 15,000-batch/day limit (and each batch can carry up to 10,000 records). Concretely: upserting 50,000 contacts via REST consumes ~50,000 calls. The same operation via Bulk API 2.0 consumes 5 batch calls. For any operation touching more than a few hundred records, Bulk API is the right tool both for performance and for limit hygiene. JSForce, the standard Node integration library, supports Bulk API 2.0 natively — usually a one-line change to a `bulk` operation.

What's the difference between REQUEST_LIMIT_EXCEEDED and EXCEEDED_ID_LIMIT?

REQUEST_LIMIT_EXCEEDED means you've hit the daily call ceiling — the integration stops working entirely until the midnight reset. EXCEEDED_ID_LIMIT is narrower: it fires when a single SOQL query asks for more than 2,000 record IDs at once (typical of an IN clause with a long list). EXCEEDED_ID_LIMIT doesn't lock you out of the API; it just rejects the one query. Fix it by chunking the ID list and querying in batches of 2,000 or fewer. The two errors get confused because both involve 'limits' — they're unrelated.

Can I request a temporary API limit increase?

Yes, for documented one-shot needs. Open a case with Salesforce Support, include your org ID, the business justification (data migration, end-of-quarter export, M&A consolidation), the duration you need, and the increased allocation amount. Most requests for 7-day doublings of the daily limit get approved within 24-48 hours. Salesforce will not grant indefinite increases — the underlying allocation is contractual. If you consistently need more, the path is either an Unlimited Edition upgrade or a paid API call add-on.

Will Salesforce notify me before I hit the daily limit?

Out of the box, no. Salesforce raises events at 50%, 80%, and 100% consumption (the LimitMonitoring event) but no email or dashboard alert fires unless you build it. The standard workaround is to subscribe to those events via a platform event listener or use a third-party monitor. BuildForce's API health check polls OrganizationLimits.DailyApiRequests every 15 minutes and projects exhaustion time from the consumption curve — usually surfacing the warning hours before the 80% built-in event fires.

Does Salesforce throttle individual integrations, or just enforce a shared org-wide limit?

Org-wide. There's no per-app cap; whichever ConnectedApp burns calls first wins. This is why a single misbehaving integration can take down every other integration in the org — your nightly NetSuite sync isn't 'protected' from a runaway HubSpot poll loop. The defensive pattern is to give critical integrations dedicated API users with usage caps enforced at the integration layer (most iPaaS tools support per-connection rate limits), so they consume their budget on a schedule rather than all-at-once.

Fix Guide

How to Fix Salesforce API Limit Errors

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

Salesforce API limit errors — REQUEST_LIMIT_EXCEEDED, EXCEEDED_ID_LIMIT, and QUERY_TIMEOUT chief among them — happen when your org has burned through its 24-hour allocation of REST and SOAP API calls. The allocation is 1,000 calls per full Salesforce license on top of an edition baseline (Enterprise: 100,000 base, capped at 1.5M; Unlimited: 1,000,000 base, capped at 5M); the counter resets at 00:00 Pacific. The immediate triage is in Setup → API Usage Summary: sort connected apps by 'Calls Used' and the top three almost always tell the story — a polling integration without backoff, a bulk job using the REST API instead of Bulk API 2.0, or an orphaned ConnectedApp tied to a deactivated user. Throttling the worst offender restores headroom within hours. The permanent fix is migrating bulk operations off REST and putting alerts on 70% consumption so you triage before integrations fail rather than at 100%, when they already have.

REQUEST_LIMIT_EXCEEDEDDaily API LimitTop Consumer IdentificationRate Throttling

Get AI-Powered Diagnosis See Pricing

API limit exhaustion almost never looks like a single broken integration — it looks like everything breaking at once. Mid-afternoon Pacific time, your HubSpot sync stops moving leads. Your Marketo lookups return empty. Your scheduled Apex jobs queue up but never run. Reports refresh to 'data unavailable'. Then everything magically resolves around 4am the next day. That pattern — multiple unrelated integrations failing in the same window and recovering on a clock — is the API-limit signature.

It tends to hit hardest during quarter-close and migration windows, because that's when one-shot bulk jobs run on top of the steady-state baseline. A team that runs comfortably at 60% utilization on a normal day can spike to 110% the day finance dumps a 200,000-record export to feed reporting.

And the obvious fix — call Salesforce and ask for more — is usually unavailable for routine consumption. Salesforce will grant a temporary increase for a documented migration or end-of-period event, but the steady-state allocation is contractual. The real fix is consumption hygiene: switching bulk to Bulk API 2.0, putting backoff on polling integrations, and revoking ConnectedApps for users who left six months ago.

Enterprise Edition allocation = 100,000 base + 1,000 per full user license, capped at 1.5M calls per rolling 24 hours. Unlimited Edition = 1,000,000 base + 1,000 per user, capped at 5M. Bulk API 2.0 batches count against a separate 15,000-batch limit, not the REST/SOAP limit.

Source: Salesforce Developer Docs — API Request Limits and Allocations (Spring '26)

Symptoms

Integrations returning REQUEST_LIMIT_EXCEEDED or EXCEEDED_ID_LIMIT errors

Scheduled jobs failing after midnight resets but failing again by afternoon

Reports and dashboards not refreshing with 'Data refresh failed' messages

Connected apps showing authentication errors that resolve at midnight

Bulk data exports timing out or returning partial results

Root Causes

Polling integrations with no backoff

Integration tools configured to poll Salesforce every minute consume 1,440+ calls per day before doing any actual work. Connected apps like HubSpot, Marketo, and ServiceNow are common culprits when configured without rate limiting.

Bulk sync jobs with per-record API calls

Sync jobs that make individual API calls per record instead of using batch endpoints can exhaust limits in minutes. A 10,000-record sync with per-record queries uses 20,000+ calls.

Report subscriptions and scheduled dashboards

Report subscriptions refresh via API. An org with 50 users each subscribed to 5 dashboards on an hourly schedule can generate thousands of API calls daily from report refreshes alone.

Orphaned integration users

Previous integrations whose access was revoked but whose connected apps still attempt API calls consume limit without delivering value. Orphaned apps can silently drain limits.

How to Fix It — Step by Step

Check current API usage

Navigate to Setup → Company Information and look at the 'API Requests, Last 24 Hours' field. If it's above 80% of your limit, proceed immediately.

Example

SELECT Id, ConnectedAppId, Count FROM OauthToken WHERE ConnectedAppId != null GROUP BY ConnectedAppId ORDER BY Count DESC LIMIT 10

Identify top consumers with API Usage report

In Salesforce Classic: Setup → Develop → API Usage. In Lightning: Setup → API Usage Summary. Sort by 'Calls Used' to find the top 5 consuming connected apps.

Throttle polling integrations

For each high-consuming integration, review its polling interval in the integration platform's settings. Change from minute-level polling to 15-30 minute intervals for non-time-sensitive syncs.

Switch bulk jobs to Bulk API 2.0

Replace REST API calls in bulk sync jobs with Salesforce Bulk API 2.0 endpoints. Bulk API calls count against a separate limit (10,000 batch calls per 24 hours) rather than the REST API limit.

Example

POST /services/data/v59.0/jobs/ingest
{
  'object': 'Contact',
  'operation': 'upsert',
  'externalIdFieldName': 'Email'
}

Remove or revoke unused connected apps

In Setup → Connected Apps OAuth Usage, identify apps with API calls but no active users. Revoke access for apps that are no longer needed.

Enable API usage alerts

Use BuildForce's API limit monitoring to receive alerts when usage exceeds 70% of your daily limit — giving you time to throttle before integrations fail.

Real-world incidents we've seen

A B2B SaaS customer whose HubSpot↔Salesforce sync was configured to poll every 60 seconds for new leads — burned through 80% of a 250,000-call/day allocation by 10am, silently blocking every other integration in the org until the midnight reset. The fix was a 15-minute polling interval and a webhook trigger for true real-time updates.
A field-service company whose nightly inventory sync upserted 18,000 records one at a time via the REST API instead of Bulk API 2.0 — 36,000+ calls per night, indistinguishable in the API log from a runaway script. Converting to a single Bulk API job dropped consumption to 6 batch calls per night.
An Enterprise org with 12 ConnectedApps tied to deactivated former-employee users — 4,200 silent calls per day collectively from background OAuth refresh attempts, none doing useful work. Revoking the OAuth grants in Setup → Connected Apps OAuth Usage freed 1.5% of the daily allocation overnight.

Let BuildForce diagnose and fix this automatically

Instead of following manual steps, connect your org and let our AI identify exactly what's broken and how to fix it — in minutes.

Book a Demo

How BuildForce prevents this in the first place

Continuous platform health checks

BuildForce surfaces this exact failure pattern automatically — no manual triage required.

AI-powered remediation guidance

Open this issue in the AI consultant for org-aware fix steps tailored to your data model.

Common Questions

More answers about this issue and how to resolve it.

Related fix guides

All fix guides

Stop debugging manually. Let AI do it.

BuildForce runs 200+ automated checks across your Salesforce org and tells you exactly what's broken and how to fix it.

Book a Demo View Pricing