Skip to main content

​
Overview

Rate limits protect Snipp from abuse and keep performance consistent for everyone. Limits apply per user, per endpoint. Hitting the cap on one endpoint does not affect requests to another.

​
API Limits

EndpointLimitWindow
GET /users/{id}No limit
GET /posts/{code}20 requestsPer 30 seconds
POST /upload20 requestsPer 30 seconds
GET /uploads20 requestsPer 30 seconds
PATCH /editUpload20 requestsPer 30 seconds
POST /appendUpload10 requestsPer minute
DELETE /deleteUpload20 requestsPer 30 seconds
POST /report-post and POST /report-user3 requests combinedPer minute
POST /upload also has an abuse safeguard. More than 8 uploads per second triggers a temporary suspension of upload access for your account.

​
Relay Limits

The Relay API matches the limits above for shared endpoints, with these additional Relay-only endpoints:
EndpointLimitWindow
GET /discoverNo limit
GET /blocksNo limit
POST /block10 requestsPer minute
POST /unblock10 requestsPer minute
PATCH /profile10 requestsPer minute
POST /profile/avatar10 requestsPer minute
POST /profile/banner10 requestsPer minute
POST /like30 requestsPer minute
GET /commentsNo limit
POST /comment5 requestsPer minute
DELETE /comment5 requestsPer minute
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:
HeaderDescription
X-RateLimit-LimitMaximum requests allowed per window
X-RateLimit-RemainingRequests remaining in the current window
X-RateLimit-ResetUnix timestamp (seconds) when the window resets
Endpoints with no limit do not include these headers.

​
Rate Limit Responses

When you exceed the limit, the API returns HTTP status 429: 
{
  "error": "Rate limit exceeded. Please try again later."
}
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 /api/v1/album and chunked-upload routes return 413 with the same fields at the top level.
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 X-RateLimit-Reset header to calculate how long to wait before retrying.
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.