In this article:

• API Rate Limit policy
• Best practices for using the API
• Recommendations for event-based & inventory data

API Rate Limit policy

Ryder API access is subject to a rate limit of 10 requests per second. This limit is intended to protect API performance and availability for all customers.

Customers are responsible for managing the volume and frequency of requests generated by their integrations and ensuring that their systems remain within the applicable rate limit. Integrations should implement appropriate throttling, request management, and retry logic, particularly when multiple processes or services are making requests concurrently.

If the rate limit is exceeded, Ryder will reject the request with an HTTP 429 (Too Many Requests) response. The response body will contain:
Rate Limit Exceeded

Requests rejected due to rate limiting are not queued by Ryder. The customer integration is responsible for determining whether and when to retry the request and should incorporate an appropriate delay to avoid repeated rate-limit violations.

The 429 response includes the following rate-limit headers. Header values are dynamic and may vary based on current request volume:

Customers should monitor these headers and design their integrations to gracefully handle 429 responses without continuously retrying requests and further exceeding the rate limit.

Back to top

Best practices for using the API

The API is designed to support operational integrations and transactional workflows. Customers should avoid using the API as a continuous data source for BI, reporting, analytics, or other applications that make frequent, recurring requests to retrieve the same or large volumes of data.

For example, repeatedly polling the API every few minutes to retrieve inventory levels, search for newly shipped orders, or otherwise capture changes that can be obtained through other available mechanisms can result in unnecessary API traffic. While periodic API requests are supported, customers are responsible for ensuring that their integrations respect the published rate limits and implement appropriate request-handling and retry logic.

Excessive API traffic can consume available rate-limit capacity and may interfere with other API operations, including order submission and other time-sensitive integration activity. This is especially important during peak periods when API traffic and operational volume may be significantly higher.

Back to top

Recommendations for event-based & inventory data

Where possible, we recommend using the following approaches for event-based and inventory data:

• Webhooks: Use the available webhooks to receive event-driven updates in real time rather than repeatedly polling the API. Webhooks are available for events such as fulfillments, receipts, inventory adjustments, and other order or item activity.
  See Webhooks for more information.
   
• Nightly Inventory Snapshot: For inventory reporting and reconciliation, use the nightly inventory snapshot rather than repeatedly querying the API for inventory levels. The snapshot is available to every customer each night through both the UI and API and provides a CSV containing inventory information for any items with inventory in the warehouse. 
  See Inventory Snapshots and Accessing Inventory Snapshot via API for more information.

If your integration requires requests to the API on a regular or recurring cadence, please send a ticket to support@whiplash.com before implementing the polling pattern. Our Tech team can help determine the most appropriate approach and identify available webhooks, snapshots, or other integration methods that may better support the use case. This helps prevent unnecessary API traffic and potential rate-limit issues as the integration scales.

Back to top