Handle Amazon SP-API rate limits: usage plans, rate-limit response headers, and backoff strategy

Steps

1. Review the usage plan for each SP-API operation in the official documentation; each operation defines a `rate` (requests per second added to a token bucket) and a `burst` (maximum token bucket size).
2. Read the `x-amzn-RateLimit-Limit` response header on successful (2xx, 400, 404) responses to get the current per-account-application rate limit for that operation; this header is absent on 401/403 responses.
3. When a 429 response is received, pause all requests to that operation and implement exponential backoff: start with a short delay (e.g., 1 second), double on each retry, and add random jitter to prevent synchronized retry storms.
4. Avoid bursting all available tokens at startup; throttle proactive polling loops to stay at or below the documented `rate` value to preserve burst capacity for urgent real-time operations.
5. For high-volume operations (e.g., catalog updates), prefer batch endpoints or Feeds API submissions over individual item calls to reduce per-unit API consumption.
6. Request a rate limit increase via the SP-API support portal for operations where documented rates are insufficient for your selling volume.