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.
Recommended Backoff
A common pattern: start at 1 second and double the wait time after each failed attempt, with optional jitter to avoid thundering-herd effects.
| Attempt | Wait before retry |
|---|
| 1 | 1 second |
| 2 | 2 seconds |
| 3 | 4 seconds |
| 4 | 8 seconds |
| 5 | 16 seconds |
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.
HTTP/1.1 429 Too Many Requests
Retry-After: 30
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:
| Time since job created | Poll interval |
|---|
| 0 – 60 seconds | Every 5 seconds |
| 60 seconds – 5 minutes | Every 30 seconds |
| 5 minutes onwards | Every 60 seconds |
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.
