Skip to main content
Nash’s APIs use rate limiting to control how many requests come in. The limit is 20 requests per second per organization, counted across your whole org, not per API key. If several systems in your organization share the API, they share this budget. A few endpoints carry lower limits of their own — the store catalog endpoints allow 10 requests per second, and custom order events (POST /v1/order/{id}/events) allow 3 requests per second per order. The limit applies to requests you make to the Nash API. It does not govern Nash’s delivery of webhooks to your endpoint, which has its own retry behavior.

​
When you exceed the limit

Requests over the limit receive an HTTP 429 Too Many Requests response. Treat a 429 as a signal to slow down, not as a failure to retry immediately.
  • Back off exponentially, with jitter. On a 429, wait before retrying and double the wait on each subsequent 429 (for example 0.5s, 1s, 2s, 4s), adding a small random jitter so retries from parallel workers don’t resynchronize.
  • Honor Retry-After when present. If a 429 response includes a Retry-After header, wait at least that long before retrying instead of using your own delay.
  • Retry idempotently. Send your own external identifier — externalId on orders, externalIdentifier on jobs (deliveries) — so a retried call references the same record instead of creating a duplicate (see create or update order by external identifier).
  • Smooth your own traffic. For bulk work, cap your client’s outbound rate below the limit (a token-bucket or a small concurrency limit) rather than bursting and relying on retries.

​
Need a higher limit?

If your organization has a sustained need above 20 requests per second, contact the Nash support team at support@usenash.com to discuss an adjustment. Share your expected peak throughput and the integration driving it.