Skip to main content

​
Overview

Rate limits protect Snipp from abuse and keep performance consistent for everyone. Limits apply per user, per endpoint, except where two endpoints are marked as sharing a bucket below.

​
API Limits

POST /upload also has an abuse safeguard. Sending more than 8 uploads within one second suspends your account. Suspended accounts lose upload access and must contact support to appeal. Team API keys are throttled with a 429 instead of being suspended.

​
Relay Limits

The Relay API matches the limits above for shared endpoints, with these additional Relay-only endpoints: GET /posts/{code} and GET /discover on Relay automatically count views per post. Views are deduplicated per IP and post: up to 3 counted views per IP per post per hour. See the Relay Reference for what Relay covers and how to authenticate.

​
Rate Limit Headers

Rate-limited responses include headers to help you track your usage: Endpoints with no limit do not include these headers.

​
Rate Limit Responses

When you exceed the limit, the API returns HTTP status 429:
The rate limit headers are still included on 429 responses so you know when to retry.

​
Weekly Usage Limit Responses

Separate from per-endpoint rate limits, every account has a weekly usage limit. Files that would push you over the limit are rejected before they are stored. The exact response shape depends on the endpoint:
  • POST /upload and POST /appendUpload return 200 with the rejected file moved to the failed array. Each entry includes error: "Weekly usage limit exceeded.", plus quota, used, and resetsAt.
  • The Website internal chunked-upload route returns 413 with the same fields at the top level.
  • The Website internal /api/v1/album route moves the rejected file to the failed array like /upload: 200 when at least one file was stored, 400 when every file failed. The fields sit at the top level only when a single file was sent.
Check your remaining usage anytime via GET /users/@me (limits.usage).

​
Handling Rate Limits

1

Check the headers

Read X-RateLimit-Remaining from each response. When it approaches 0, slow down.
2

Detect the 429 status

Check for HTTP status 429 in your API responses.
3

Wait until reset

Use the Retry-After header on the 429 as the wait time in seconds, or calculate it from X-RateLimit-Reset.
4

Use exponential backoff

If requests continue to fail, double the wait time with each retry (for example, 1s, 2s, 4s, 8s).

​
Best Practices

  • Space out bulk uploads. When uploading multiple files, add a short delay between each request rather than sending them all at once.
  • Cache user data. Avoid calling /users/@me repeatedly. Fetch it once and reuse the result for the duration of your session.
  • Batch where possible. Reduce the total number of API calls by combining logic on your end instead of making multiple requests for related data.
  • Monitor your usage. If you consistently hit rate limits, consider whether your integration can be optimized to make fewer requests.