Load Shedding and Rate Limiting

In SCAPI, we use different techniques to maximize the availability of your instance:

• Load shedding: APIs intentionally reject incoming requests to prevent the system from becoming overloaded.
• Rate limits: The frequency at which API clients can make requests in a given timeframe is controlled.

With these protection mechanisms, customers have uninterrupted access to your storefront.

Load Shedding

If the system reaches a load threshold after scaling to maximum capacity, an HTTP 503 status code is returned. Load shedding is not used for checkout-related endpoints, such as the Shopper Baskets and Shopper Orders API families, to ensure that shoppers can complete an in-progress checkout.

Endpoints protected by load shedding include the following HTTP response headers:

• sfdc_load: System capacity in use (percentage): 0 to 100
• sfdc_load_status: Relative health of the system:
  • WARN: returned at 80% system capacity
  • THROTTLE: returned at 90% system capacity

When system capacity reaches 80% or 90%, the sfdc_load_status header is sent. note: Some API families, such as SLAS and Omnichannel Inventory (OCI) only use rate limiting.

Rate Limiting

To maintain the quality of service and improve platform stability, some B2C Commerce APIs have rate limits. When the number of requests received reaches the rate limit, the API returns an HTTP 429 response.

Rate limits can be adjusted based on specific customer scenarios or use cases. Contact your Customer Success Manager or Account Executive for questions around rate limits, use cases, and potential adjustments required for these rates.

important: All other endpoints not mentioned in this document are no longer rate limited.

How to Read the Numbers

The following tables show the rate limits for different API families. The limit column shows the maximum number of requests allowed for specific endpoints.

Shopper Login and API Access Service (SLAS)

SLAS enforces rate limits separately for each instance (SLAS tenant):

• Production instances: 24,000 requests per minute (RPM) per instance.
• Non-production instances: 500 RPM per instance. Each non-production instance (for example, a Development and a Staging instance) has its own 500 RPM allowance.
• 25 RPM for these endpoints: getJwksUri and getWellknownOpenidConfiguration.

When a rate limit is reached, SLAS responds with an HTTP 429 Too Many Requests with an HTTP response header Retry-After. The value in the Retry-After header is set to the time in seconds to wait before retrying the request:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600

Your client code must be able to handle this response. To make sure that the next request is successful, always wait for the specified time before retrying.

Omnichannel Inventory API Family

Be aware that the rate limits defined for OCI are rolling rate limits. This means that there’s a maximum number of concurrent requests allowed per time period defined. This helps OCI to prevent denial-of-service attacks by limiting the amount of traffic that can be sent from one organization over that defined period. The limit is measured in seconds and will reset at regular intervals so it's always "rolling" forward. If any organization exceeds its allotted quota for too long, it is blocked until its usage drops below the threshold again. By setting these rules, OCI is able to detect suspicious activity and block the traffic before it becomes a problem for all consumers of the service.

Rate limits are outlined below, by service, by endpoint, and by request type.

The following APIs are included in the omnichannel inventory API family:

Inventory Availability

Base URI: https://{shortCode}.api.commercecloud.salesforce.com + /inventory/availability/v1/organizations/{organizationId} +

Inventory Impex

Base URI: https://{shortCode}.api.commercecloud.salesforce.com + /inventory/impex/v1/organizations/{organizationId} +

Inventory Reservation

Base URI: https://{shortCode}.api.commercecloud.salesforce.com + /inventory/reservation/v1/organizations/{organizationId} +