Rate Limits

Protected API endpoints have customer and shared capacity limits. Pace your requests within both limits and honor Retry-After when the service is busy.

Current limits

Sales-order creation consumes the normal customer allowance and the additional 10 requests/minute order allowance. Portal service traffic has a separate capacity allowance.

API keys mapped to the same customer share the customer allowance. A key without a customer mapping receives its own authenticated-consumer allowance. Changing paths, query strings, headers, request IDs, or source IPs does not reset either allowance.

Rate-limit responses

Gateway rate-limit rejections return 429 with a Retry-After header specifying the delay in seconds before retrying. Use it when present; otherwise use bounded exponential backoff with jitter. Responses do not include x-ratelimit-limit, x-ratelimit-remaining, or x-ratelimit-reset.

The service can also return 503 with Retry-After when its processing capacity is full. Use bounded retries and retain the same idempotency key and request body when retrying an order submission.

When you exceed a rate limit, the API returns:

Code
 
{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Rate limit exceeded. Retry after the reset window.",
    "request_id": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Client guidance

• Pace normal catalog requests within the customer limit and honor Retry-After on 429 responses.
• Use updated_since for incremental syncing and ?limit=200 for large catalog pages.
• If a sales-order POST response leaves acceptance uncertain, replay the identical body with the same Idempotency-Key. This does not retry failed processing. Corrected orders require a new key and safe consumer duplicate handling. Do not automatically resubmit attachment or ambiguous processing failures; contact support because an order may already exist.