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.

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.

To ensure 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. Contact your Customer Success Manager or Account Executive for questions around rate limits, use cases, and potential adjustments required for these rates.

In the tables below you can see the rate limits for different API families. The limit column shows the maximum number of requests allowed for specific endpoints.

SLAS supports the following rate limits:

• 24,000 requests per minute (RPM) per tenant for production instances.
• 500 RPM per tenant for non-production instances.
• 25 RPM for the following 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:

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

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:

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

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

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