Org Limit
An Org Limit in Salesforce is an organization-wide cap on a shared resource that the whole org draws from over a set window, such as daily API requests, data storage, file storage, or asynchronous Apex executions.
Definition
An Org Limit in Salesforce is an organization-wide cap on a shared resource that the whole org draws from over a set window, such as daily API requests, data storage, file storage, or asynchronous Apex executions. Because Salesforce runs on multi-tenant infrastructure, where many customers share the same servers, these limits protect every tenant from any single org consuming more than its fair share.
Org Limits are different from Governor Limits. An Org Limit is a budget the entire org spends across a period (often a rolling 24 hours) or a total ceiling like storage. A Governor Limit constrains what one Apex transaction may do (SOQL queries, DML rows, CPU time) and resets when that transaction ends. You read current Org Limit consumption through the Limits REST API and several Setup pages.
How org limits keep a shared platform fair
The multi-tenant reason these limits exist
Salesforce does not give each customer a private server. Thousands of orgs share the same pooled compute, database, and storage, and the platform schedules everyone's work together. That design keeps the service affordable and lets Salesforce push three upgrades a year to all orgs at once. It also means one org cannot be allowed to consume resources without bound, because its spike would slow down or starve its neighbours. Org Limits are the mechanism that draws the boundary. Each org receives an allocation for shared resources, and the platform meters consumption against it. When an allocation is spent, further requests of that type are refused until the window resets or you buy more capacity. The limits are not arbitrary punishment. They are the budget that lets the platform promise predictable performance to everyone on it. Understanding this framing helps you treat allocations as a planning input rather than a surprise. You design integrations and data models knowing there is a ceiling, so you build with headroom instead of discovering the wall during a busy quarter.
Org limits versus governor limits
These two ideas get mixed up constantly, so it is worth separating them cleanly. A Governor Limit is per transaction. It caps what a single execution context can do, for example 100 synchronous SOQL queries, 10,000 DML rows, or a CPU time budget, and Salesforce resets the counters the instant that transaction finishes. Governor Limits stop one badly written request from monopolising a shared thread. An Org Limit is per org and per period. It caps how much the whole organization can do across many transactions and users, such as the total API calls allowed in a rolling 24 hours, or how many megabytes of records you may store overall. One is a runtime guardrail on code, the other is an account-level resource budget. A practical tell: if hitting the limit throws a System.LimitException inside Apex mid-execution, you are looking at a Governor Limit. If the limit shows up as a tracked allocation in the Limits API or on a Setup usage page, and exhausting it blocks new requests or new data rather than one transaction, that is an Org Limit.
The daily API request allocation
The most watched Org Limit is the daily API request count. It covers calls to the REST, SOAP, Bulk, and Connect APIs, measured over a rolling 24-hour window rather than a fixed midnight reset. Paid editions start with a base allocation (Enterprise Edition begins at 100,000 requests per 24 hours) and the ceiling rises with the user licenses your org is provisioned. If your integrations need more, you can purchase additional capacity in increments that range from 200 up to 10,000 requests per 24-hour period. Salesforce also tracks a longer 30-day aggregate, so both the daily and monthly figures matter for heavy integration estates. This allocation is where most production incidents originate. A nightly batch job that loops one record at a time, a chatty middleware poll, or a runaway retry loop can drain tens of thousands of calls fast. When the org runs out, every external system that talks to Salesforce starts receiving errors at once, which is why teams treat this number as a first-class operational metric and not an afterthought.
Data storage and file storage
Storage is the other Org Limit that quietly causes outages. Salesforce splits it into two pools. Data storage holds your records: accounts, contacts, opportunities, cases, custom object rows, and similar. Most records count as a flat 2 KB each regardless of how many fields they carry, which makes record counts, not field widths, the thing that drives consumption. File storage is separate and holds attachments, Salesforce Files, content libraries, the Documents tab, and user photos. Enterprise and Unlimited editions start around 10 GB of data storage plus a per-user increment (roughly 120 MB per standard licensed user) and a base block of file storage. When data storage fills, you cannot create new records and inserts fail, which feels like a sudden outage to end users and integrations alike. The fix is rarely just buying more space. Large orgs archive aging records into Big Objects, offload documents to external stores, and prune obsolete data on a schedule. Watching the trend line matters more than the single number, because storage creeps up gradually and then crosses the line on an ordinary Tuesday.
Reading limits through the Limits REST API
Salesforce exposes live consumption programmatically through the Limits resource in the REST API. A GET to /services/data/vXX.0/limits returns a JSON map where each entry reports a Max (your total allocation) and a Remaining (what is left). The named entries cover the resources you most need to watch, including DailyApiRequests, DataStorageMB, FileStorageMB, DailyAsyncApexExecutions, DailyBulkApiBatches, ConcurrentAsyncGetReportInstances, ConcurrentSyncReportRuns, HourlyTimeBasedWorkflow, MassEmail, and SingleEmail. The values are accurate to within roughly five minutes of actual consumption, so they suit dashboards and scheduled health checks rather than to-the-millisecond gating. Teams wire this endpoint into monitoring tools to alert before a ceiling is reached, and integration code can read it to back off gracefully when Remaining runs low instead of hammering the org until it errors. Because the same endpoint surfaces many limits in one call, it is an efficient single place to build org-wide observability rather than scraping several Setup screens by hand.
Monitoring and notifications in Setup
You do not have to write code to keep an eye on Org Limits. Setup gives admins several windows into consumption. The Company Information page shows API Requests, Last 24 Hours alongside other allocation figures. The System Overview page presents usage as a percentage of your Daily API Request Limit and flags how close you are to other ceilings. The Storage Usage page breaks down data and file storage by object and by user, which is the fastest way to find what is eating space. Salesforce also lets you create API Usage notifications that email a chosen user when consumption crosses a threshold. Three common configurations are a 50 percent alert sent at most once every 24 hours, an 80 percent alert sent every four hours, and a 90 percent alert sent every hour. Setting these up turns a silent ceiling into an early warning. The pattern that works is layered: passive Setup pages for ad hoc checks, notifications for hands-off alerting, and the Limits API for anything that needs to react automatically.
Designing to stay under the ceiling
Most Org Limit problems are architecture problems wearing a usage badge, so the durable fixes live in design. For API requests, the biggest lever is batching. Composite and Bulk operations let one call move many records, turning a thousand row-by-row updates into a handful of requests. Caching reference data, removing redundant polling, and replacing polling with platform events or change data capture all cut call volume sharply. For storage, the levers are archival and hygiene: move cold records into Big Objects or an external store, delete duplicates and stale leads, and keep attachments out of the data pool by using Files and external storage. For asynchronous Apex and bulk batches, schedule heavy jobs in off-peak windows and respect the daily counts so reports and integrations are not starved. The common thread is headroom. Aim to run well below each ceiling during normal load, not right against it, because spikes from a campaign, a data migration, or a partner's bad deploy will eat the gap. Treat allocations as a capacity budget you plan around, the same way you would plan around a fixed monthly cloud spend.
How to monitor org limits before you hit them
You cannot create an Org Limit, since Salesforce sets the allocations for your edition and license count. What you can configure is monitoring, so the org warns you before a ceiling is reached. The main tool is an API Usage notification, set up in Setup under Company Information.
- Open API usage notifications
In Setup, go to Company Information, then find the API Usage Notifications related area, or search Setup for API Usage Notifications directly.
- Create a notification
Add a new notification, choose the recipient user, and set the threshold percentage of the Daily API Request Limit you want to be warned at.
- Set the interval
Choose how frequently the alert repeats while the threshold stays breached, then save. Add a second, higher-threshold notification for escalating urgency.
- Cross-check with the Limits API
For automated reactions, call /services/data/vXX.0/limits on a schedule and alert when Remaining for DailyApiRequests, DataStorageMB, or FileStorageMB drops too low.
The user who receives the threshold email. Pick a monitored team alias or an admin who acts on alerts, not a personal inbox that may go unwatched.
The share of the Daily API Request Limit that triggers the email, for example 50, 80, or 90 percent. Lower thresholds give earlier warning and more lead time to react.
How often a breaching threshold re-sends. Common pairings are 50 percent every 24 hours, 80 percent every four hours, and 90 percent every hour for tightening urgency.
Not a notification setting, but the Storage Usage page in Setup is where you confirm data and file storage headroom and see which objects consume the most space.
- API Usage notifications cover the daily API request count, not storage; watch storage separately on the Storage Usage page or via DataStorageMB in the Limits API.
- The Limits API values lag real consumption by up to about five minutes, so treat them as near-real-time, not exact gating thresholds.
- The daily API limit is a rolling 24-hour window, not a fixed midnight reset, so a spike can keep you over the line longer than you expect.
- Raising the ceiling usually means buying capacity or licenses; tune integration design first, because batching often removes the need entirely.
Prefer this walkthrough as its own page? How to Org Limit in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- List Org Limits, REST API Developer GuideSalesforce
- Data and File Storage AllocationsSalesforce
Straight from the source - Salesforce's reference material on Org Limit.
- Limits, REST API Developer GuideSalesforce
- API Limits and Monitoring Your API UsageSalesforce
Hands-on resources to go deeper on Org Limit.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does an Org Limit define in Salesforce?
Q2. How are Org Limits tracked and why are they enforced?
Q3. How does an Org Limit differ from a Governor Limit?
Discussion
Loading discussion…