Skip to main content
Sly enforces rate limits per IP and per authenticated actor. Standard plans share a generous budget; tighter limits apply to auth endpoints and abusive patterns.

​
Default limits

Enterprise plans get higher ceilings and/or dedicated rate-limit buckets — contact support.

​
Response headers

Every response includes:
  • Limit — total requests in the current window
  • Remaining — requests left before throttling
  • Reset — Unix timestamp when the window resets

​
When you hit the limit

Sly returns 429 Too Many Requests with a Retry-After header:
Respect Retry-After. Don’t retry immediately — it extends the window.

​
Graceful handling in the SDK

The Node SDK automatically respects 429 + Retry-After:
Custom backoff for bulk operations:
With concurrency set below your rate limit, you rarely hit 429 at all.

​
Bulk operations

For high-volume workflows, use batch endpoints instead of parallel individual requests:
  • POST /v1/transfers/batch — hundreds of transfers in one request
  • POST /v1/acp/checkouts/batch — batch ACP checkouts
  • POST /v1/ucp/checkouts/batch — batch UCP checkouts
Batch endpoints count as one request against your limit.

​
Webhook delivery vs. rate limits

Webhook delivery doesn’t count against your rate limit — Sly is delivering to you, not the other way around. But your response time affects our throughput: respond fast and async-process if you need more than a few hundred ms.

​
Different environments, different limits

Sandbox and production have separate budgets. Hitting sandbox’s 1k/min cap doesn’t slow down your production traffic. Dev-testing heavy operations in sandbox won’t starve your live workload.