Please Click Here for a PDF of the document below.

​
1. API Endpoint and Method

Endpoint: https://rest.wd-fs.com/api/v1/Orders/Detail/{accountNumber}/{orderRef}
Method: GET
Purpose: Retrieves detailed information for a specific order.

​
2. Rate Limits

To maintain fair usage and ensure system stability, the following limits apply: • **Per-Token Limit: **150 requests per minute (RPM)
Maximum rate for a single authentication token (user or application). • **Per-IP Limit: **1000 RPM
Maximum combined requests from the same IP address. • Global Limit: 5000 RPM
Maximum total requests across all users of the API. The per-token limit is the most restrictive and typically the primary factor to manage. For a stable production environment, we recommend a steady-state retrieval strategy to avoid spikes that could trigger rate limit errors. • Steady Rate: Aim for 120–130 requests per minute (RPM) per token. This remains below the per-token limit while ensuring high throughput. • Concurrency: Use 10–15 parallel requests to maintain the steady rate without overloading the system.
This approach reduces the risk of 429 errors and promotes efficient integration.

​
4. Handling Rate Limit Errors (HTTP 429)

If you receive an HTTP 429 response, the rate limit was temporarily exceeded. **Best Practices: **
  • Do not retry immediately. Retrying too quickly can worsen the issue.
  • Use exponential backoff with jitter: -Exponential Backoff: Increase wait time between retries (e.g., 1s → 2s → 4s → 8s). **-Jitter: **Add a small random delay (e.g., 0–500ms) to prevent synchronized retry spikes.
Following this pattern ensures system stability and reliable access to the API. By following these guidelines, your integration will maximize throughput, minimize errors, and maintain a reliable connection to the Get Order Detail API.