Salesforce integrations rarely run into API limits during the early stages of a project. The real challenges typically emerge as organizations scale their Salesforce ecosystem, connect additional business applications, automate more workflows, and increase the volume of data exchanged between systems.

Without proper monitoring and optimization, growing API consumption can lead to slower integrations, synchronization delays, failed automations, and eventually the REQUEST_LIMIT_EXCEEDED error. These issues don’t just affect IT teams—they can disrupt sales, customer service, finance, and other business-critical operations that rely on timely data synchronization.

Understanding how Salesforce API limits work is therefore essential for building scalable integrations, maintaining reliable system performance, and supporting long-term business growth.

If you’re designing new integrations or reviewing an existing architecture, our guide to Salesforce API Integration: Best Practices and Common Pitfalls explains how architectural decisions influence performance, scalability, and API consumption from the very beginning.

In this article, you’ll learn:

• what Salesforce API limits are and why they exist;
• how the Daily API Request Limit differs from the Monthly API Entitlement;
• what counts as an API request;
• how to monitor API usage;
• common causes of excessive API consumption;
• practical strategies for reducing API usage without sacrificing performance.

Why Salesforce API Limits Matter

Salesforce API limits are often viewed as technical restrictions, but in practice they are an important part of building reliable enterprise integrations.

Every API request consumes shared platform resources. As organizations integrate Salesforce with ERP systems, marketing platforms, customer portals, e-commerce applications, data warehouses, and third-party services, API traffic increases steadily. Without proper governance, inefficient integrations can consume thousands of unnecessary requests every day.

Consider a simple example.

An external system polls Salesforce every minute to check whether records have changed.

• 1 request every minute
• 60 requests every hour
• 1,440 requests every day

Now imagine ten different applications using the same approach. Suddenly, more than 14,000 API requests are consumed every day—even if no data has actually changed.

A more scalable architecture would use event-driven mechanisms such as Platform Events or Change Data Capture, allowing systems to exchange information only when updates occur. This significantly reduces unnecessary API traffic while improving overall integration performance.

Designing efficient integrations from the start is one of the most effective ways to prevent API-related issues as your Salesforce environment grows. Our article on Salesforce Integration Architecture: Best Practices for Scalable Systems explores architectural patterns that help organizations build scalable and resilient integration landscapes.

What Are Salesforce API Limits?

Salesforce API limits define how many API requests an organization can send to Salesforce within a specific period. These limits help ensure fair resource allocation across Salesforce’s multi-tenant infrastructure while maintaining platform stability, performance, and availability for every customer.

Every request made through the REST API, SOAP API, Bulk API, Connect API, or other Salesforce APIs contributes to your organization’s API usage.

However, Salesforce doesn’t enforce a single API limit. Instead, the platform applies several categories of limits, each protecting different platform resources.

The most common API-related limits include:

One of the most common misconceptions is that Salesforce API limits and Apex governor limits are the same thing.

They serve different purposes.

API limits regulate requests entering Salesforce from external applications, while governor limits control how platform resources are consumed inside Salesforce during Apex execution.

For example, an integration may successfully submit an API request, but the Apex transaction triggered by that request can still fail because it exceeds governor limits such as CPU time or SOQL query limits.

Similarly, services including Bulk API, Salesforce Functions, Platform Events, and Change Data Capture introduce their own service-specific restrictions that operate independently from the Daily API Request Limit.

Salesforce publishes the latest platform limits in the official API Limits Cheat Sheet.

Understanding the Daily API Request Limit

The Daily API Request Limit is the primary API usage metric that Salesforce administrators and integration architects should monitor.

It represents the number of API requests an organization can consume during a rolling 24-hour period.

Unlike many cloud platforms, Salesforce does not reset API usage at midnight.

Instead, every request remains part of the calculation for exactly 24 hours before it automatically expires from the usage total.

For example:

This rolling-window approach provides a more accurate representation of real API activity than a traditional calendar-day reset.

The exact Daily API Request Limit depends on several factors, including:

• your Salesforce Edition;
• the number and type of user licenses;
• purchased API capacity;
• your organization’s configuration.

Because these values vary between organizations, Salesforce recommends checking the current allocation directly within your org rather than relying on generic reference tables.

More information is available in Salesforce Developers’ article API Limits and Monitoring Your API Usage.

Is the Daily API Request Limit a Hard Limit?

Not exactly.

One of the biggest misconceptions is that Salesforce immediately blocks all API traffic as soon as the Daily API Request Limit is reached.

In reality, Salesforce treats the published Daily API Request Limit as a soft operating limit.

Organizations may temporarily continue processing requests beyond their allocated daily limit. However, this temporary overage should never be treated as additional available capacity or relied upon during normal operations.

If API traffic continues to increase, Salesforce activates an internal protection mechanism designed to preserve overall platform stability. Once that threshold is reached, new API requests begin receiving the following response:

403 REQUEST_LIMIT_EXCEEDED

Salesforce doesn’t publish the exact value of this internal system protection threshold. For that reason, organizations should aim to operate comfortably below their allocated Daily API Request Limit and investigate unusual spikes in API consumption before they become production issues.

What Happens When the Limit Is Exceeded?

Application
      │
      ▼
API Requests
      │
      ▼
Daily API Request Limit Reached
      │
      ▼
Temporary Overage (Possible)
      │
      ▼
Internal Protection Threshold
      │
      ▼
403 REQUEST_LIMIT_EXCEEDED
      │
      ▼
Requests Rejected Until Usage Drops

When API requests begin to fail, the impact is often much broader than a single integration.

Business processes that may be affected include:

• ERP synchronization;
• marketing automation;
• payment processing;
• customer portals;
• mobile applications;
• middleware platforms;
• third-party integrations.

For many organizations, proactive API monitoring is significantly less expensive than troubleshooting multiple integration failures after API capacity has already been exhausted.

Monthly API Entitlement

The Monthly API Entitlement is frequently confused with the Daily API Request Limit, but these metrics serve different purposes.

While the Daily API Request Limit governs operational API traffic over a rolling 24-hour period, the Monthly API Entitlement provides a broader view of API consumption across a rolling 30-day window. Its primary purpose is capacity planning, helping organizations evaluate long-term API usage trends rather than enforcing operational restrictions.

Importantly, exceeding the Monthly API Entitlement does not automatically block API requests.

Instead, Salesforce uses this metric to help customers understand whether their long-term API consumption aligns with their licensed capacity and whether additional optimization—or additional API capacity—may be required in the future.

Together, these two metrics provide both an operational and a strategic view of API consumption, allowing organizations to manage current usage while planning for future growth.

Other Salesforce API Limits You Should Know

While the Daily API Request Limit is the most closely monitored metric, it’s only one component of Salesforce’s broader API governance model. Depending on your architecture, data volumes, and integration patterns, several additional limits may affect application performance, scalability, and reliability.

Understanding these limits helps integration teams identify potential bottlenecks before they impact production environments.

Concurrent API Request Limits

The Concurrent API Request Limit controls the number of long-running API requests that Salesforce can process simultaneously.

Unlike the Daily API Request Limit, which measures the total number of requests over time, concurrent limits focus on requests that remain active for an extended period. Their primary purpose is to prevent a small number of slow integrations from consuming excessive platform resources.

These limits are most commonly affected by:

• inefficient SOQL queries;
• synchronous integrations processing large datasets;
• middleware waiting for responses from external systems;
• API requests that trigger complex Apex logic;
• long-running transactions.

When concurrent request limits are reached, organizations may experience:

• increased response times;
• queued requests;
• timeout errors;
• rejected requests even though plenty of daily API capacity remains.

In many cases, improving query performance, optimizing Apex code, or redesigning the integration flow resolves the issue without requiring additional API capacity.

Salesforce documents these limits in the official API Limits Cheat Sheet.

Bulk API Limits

Processing thousands—or even millions—of records through standard REST or SOAP API requests is rarely the most efficient approach.

Salesforce provides Bulk API specifically for high-volume asynchronous data processing.

Typical use cases include:

• large data migrations;
• scheduled imports and exports;
• ETL processes;
• data warehouse synchronization;
• ERP integrations.

Rather than sending thousands of individual requests, Bulk API processes data in batches, significantly reducing network overhead and improving scalability.

However, Bulk API introduces its own operational limits, including restrictions related to:

• batch size;
• job size;
• processing time;
• concurrency.

Organizations should review these limits when designing large-scale integrations.

Official documentation:

Bulk API Limits

Salesforce Functions Limits

Organizations using Salesforce Functions should also consider service-specific execution limits.

Although Functions execute outside the Salesforce core runtime, they still have restrictions related to:

• execution time;
• memory allocation;
• concurrency;
• invocation limits;
• communication with Salesforce services.

Understanding these limits helps developers design scalable serverless solutions while avoiding unexpected execution failures.

Official documentation:

Salesforce Functions Limits

What Counts as an API Request?

One of the most common questions administrators ask is:

What actually counts as a Salesforce API request?

In general, every request sent to a Salesforce API counts toward your organization’s API usage.

This includes requests made through:

• REST API
• SOAP API
• Bulk API
• Composite API
• Connect API
• Tooling API
• Metadata API

However, not every integration strategy consumes API resources equally.

For example, updating ten records individually through the REST API requires ten separate API calls.

Using the Composite API, those same operations can often be executed within a single HTTP request, reducing network overhead and simplifying integration logic.

Similarly, Bulk API minimizes request volume by processing records in batches rather than individual transactions.

Choosing the appropriate API for each workload is one of the simplest ways to reduce unnecessary API consumption.

Our guide on Salesforce API Integration: Best Practices for Scalable Systems explains when to use REST API, Composite API, Bulk API, and event-driven integrations to build scalable architectures.

How to Check Salesforce API Usage

Monitoring API consumption should be part of every Salesforce administrator’s routine.

Salesforce provides several built-in tools that allow organizations to monitor API usage, identify trends, and detect unusual activity before integrations begin to fail.

Using multiple monitoring methods together provides the clearest picture of API health across your Salesforce environment.

Company Information

The Company Information page provides a quick overview of your organization’s current API allocation and usage.

Administrators can immediately see:

• Daily API Request Limit;
• API requests used;
• remaining API capacity.

For many support investigations, this page is the fastest way to determine whether API consumption is contributing to integration failures.

System Overview

The System Overview page offers another high-level snapshot of Salesforce resource utilization.

Although it doesn’t provide detailed analytics, it allows administrators to quickly assess overall system health, including API usage trends.

REST API Limits Resource

Developers can retrieve current API usage programmatically through Salesforce’s REST Limits Resource.

This endpoint returns current allocations and remaining limits for multiple Salesforce services, making it ideal for:

• custom monitoring dashboards;
• middleware platforms;
• automated health checks;
• DevOps monitoring.

Documentation:

REST API Limits Resource

Sforce-Limit-Info Response Header

Many Salesforce REST API responses include the Sforce-Limit-Info response header.

This allows applications to monitor API consumption without making additional monitoring requests.

Example:

Sforce-Limit-Info: api-usage=2450/100000

In this example:

• 2,450 API requests have been consumed.
• 100,000 requests are available within the current rolling 24-hour window.

Because the header is returned as part of normal API responses, many integration platforms use it to display real-time API usage dashboards.

Official documentation:

API Usage Response Headers

Configure API Usage Notifications

Monitoring dashboards are useful, but administrators shouldn’t have to check them constantly.

Salesforce allows organizations to configure API Usage Notifications, automatically sending email alerts when API consumption reaches predefined thresholds.

Typical alert levels include:

• 50%
• 75%
• 90%
• 95%

These notifications give administrators time to investigate unexpected spikes before integrations begin failing.

For business-critical environments, combining automated notifications with regular API monitoring significantly reduces the risk of service disruptions.

Use Event Monitoring for Advanced Analytics

Organizations that require deeper operational visibility can use Event Monitoring.

Unlike standard monitoring tools, Event Monitoring provides detailed information about API activity across the organization.

Administrators can analyze:

• API request volumes;
• authentication events;
• connected applications;
• user activity;
• integration patterns;
• security events.

This information helps answer questions such as:

• Which integration consumes the most API requests?
• Which connected application generated yesterday’s traffic spike?
• Are API requests increasing over time?
• Is unusual API activity coming from a specific user or integration?

For enterprise environments with dozens of connected systems, Event Monitoring is often one of the most valuable troubleshooting and governance tools available.

Common Causes of High API Usage

Organizations rarely exceed Salesforce API limits because of a single integration.

Instead, API consumption usually increases gradually as additional systems, automations, and business processes are introduced.

Some of the most common causes include:

• frequent polling instead of event-driven integrations;
• duplicate synchronization jobs;
• requesting the same data repeatedly;
• processing records individually instead of in batches;
• inefficient retry mechanisms;
• unnecessary authentication requests;
• poorly optimized middleware;
• overlapping integrations performing identical tasks.

For example, polling Salesforce every minute to check for updates generates over 1,400 API requests per day for a single integration—even if no records have changed.

Replacing polling with Platform Events or Change Data Capture can dramatically reduce unnecessary API traffic while improving synchronization speed.

Organizations reviewing their integration architecture should also consider the recommendations in Salesforce Integration Architecture: Best Practices for Scalable Systems and Salesforce API Integration: Best Practices for Scalable Systems.

Best Practices to Reduce API Consumption

Reducing API usage isn’t about making fewer requests—it’s about making smarter ones.

Some of the most effective optimization strategies include:

Use Composite API

Bundle related operations into a single request whenever possible to reduce HTTP overhead.

Use Bulk API for Large Datasets

Process thousands of records asynchronously instead of sending individual REST requests.

Replace Polling with Event-Driven Integrations

Use Platform Events or Change Data Capture to exchange information only when data changes.

Cache Frequently Requested Data

Avoid repeatedly requesting the same information when it changes infrequently.

Batch Operations

Group related updates into fewer transactions rather than processing records one by one.

Reuse OAuth Access Tokens

Avoid requesting new tokens for every transaction.

Organizations should also follow the security recommendations described in Secure Salesforce Integrations: Enterprise Security Best Practices and Salesforce OAuth Security Best Practices for Enterprise Systems.

Build an API Governance Strategy

Successful organizations don’t simply monitor API usage—they manage it.

A mature API governance strategy typically includes:

• continuous monitoring;
• automated alerts;
• integration ownership;
• API usage dashboards;
• architecture reviews;
• capacity planning;
• periodic optimization initiatives.

Treating API capacity as a managed resource helps prevent outages while supporting future business growth.

When Should You Buy More API Capacity?

Purchasing additional API capacity should be considered only after existing integrations have been reviewed and optimized.

Additional capacity may be appropriate when:

• API usage consistently approaches the Daily API Request Limit;
• integrations have already been optimized;
• business growth requires significantly more connected systems;
• planned projects will substantially increase API traffic.

For most organizations, architectural improvements deliver greater long-term value than simply increasing API capacity.

How Success Craft Can Help

As Salesforce environments grow, managing API consumption becomes increasingly complex.

Success Craft helps organizations design scalable integration architectures, optimize API usage, modernize legacy integrations, and implement governance strategies that support long-term business growth.

Whether you’re building a new integration ecosystem or improving an existing one, our team can help identify inefficient API usage patterns and implement scalable, reliable integration solutions.

Learn more about our services:

• Services
• Contact Us

Conclusion

Salesforce API limits are more than platform restrictions—they’re an important consideration when designing scalable, reliable, and high-performing integrations.

Organizations that monitor API usage proactively, choose the right integration patterns, and optimize API consumption early are far less likely to encounter production issues as their Salesforce ecosystem grows.

Rather than viewing API limits as an obstacle, treat them as a framework for building more efficient, resilient, and future-ready integrations.