Skip to main content
To ensure platform stability and consistent performance for all partners, the Snappy API implements rate limiting on all endpoints.

​
Standard Limits

The Snappy API has a standard limit of 100 requests per second (RPS) per Company. This limit applies across all V2 and V3 endpoints in aggregate - they share a single bucket per Company.
If your use case requires a higher throughput, please contact your Snappy account manager to discuss your needs.

​
Handling Throttling

If you exceed the rate limit, the API returns a 429 Too Many Requests HTTP status code. Your integration should handle these responses gracefully using exponential backoff - wait a short period before retrying, and increase the wait time with each subsequent attempt. A common pattern: start at 1 second and double the wait time after each failed attempt, with optional jitter to avoid thundering-herd effects. Cap retries at 5 attempts and surface the failure to your application after that.

​
Retry-After Header

When the API returns 429, check the Retry-After response header (if present) for the number of seconds to wait before retrying. When Retry-After is provided, prefer it over your own backoff schedule.

​
Bulk Export Endpoints

The V3 catalog export endpoints (GET /v3/products/export, POST /v3/products/exports) traverse the full catalog and produce significantly larger responses than standard list endpoints. Treat them differently from regular reads.

​
Synchronous Export

GET /v3/products/export returns every matching product in a single response.
  • Call sparingly. This endpoint is intended for periodic catalog syncs (e.g. nightly), not real-time browse traffic. For real-time use cases, use the paginated list endpoints (GET /v3/products).
  • Honor 413 Payload Too Large. When the export would exceed the response size limit, the endpoint returns 413 - fall back to the asynchronous export rather than retrying.
  • Use compression. Send Accept-Encoding: gzip (or br, zstd, deflate) to reduce transfer size.

​
Asynchronous Export

For larger result sets, kick off an asynchronous export job (POST /v3/products/exports) and poll for status. Polling cadence matters - hammering the status endpoint counts against your rate limit and provides no benefit. Recommended polling pattern: Stop polling once status is completed or failed. Download the file(s) from the downloadUrls map before the export record expires (48 hours after creation) - expired records require a new export job.

​
Best Practices

  • Batch where possible. Many endpoints (e.g. POST /v2/gifts) accept arrays of items in a single request. Sending one batched request for 50 recipients is far cheaper than 50 individual requests.
  • Cache catalog data. Products, variants, and brands change infrequently. Caching responses locally (with a reasonable TTL, e.g. 1 hour) drastically reduces request volume.
  • Avoid polling for state. When a webhook exists for the event you care about (gift claimed, order shipped, etc.), use the webhook instead of polling. See Webhook Event Types.
  • Spread bulk operations. When seeding a campaign with thousands of recipients, spread the work over time rather than firing all requests at once.
Last modified on June 17, 2026