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 all Nash API endpoints — not per key or per endpoint. If several systems in your organization share the API, they share this budget. 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 externalId on order and job requests so a retried call references the same record instead of creating a duplicate (see API Key and Org ID).
  • 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.