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 endpoints are marked as sharing a bucket below.

​
API Limits

POST /upload also has an abuse safeguard. Sending more than 10 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 when at least one other file was stored. Each entry includes error: "Weekly usage limit exceeded.", plus quota, used, and resetsAt.
  • When every file in the request is rejected, the status is 400. A multi-file request returns error: "All files failed to upload." alongside the same failed array. A single-file request returns the reason at the top level, with quota, used and resetsAt beside it whenever the quota was reserved per file: POST /appendUpload, and POST /upload on a team key.
  • A single-file POST /upload on a personal key is the exception. Its quota is reserved during the insert, so it returns 400 with error: "Weekly usage limit exceeded." and no quota fields.
  • 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.