Documentation Index
Fetch the complete documentation index at: https://docs.snipp.gg/llms.txt
Use this file to discover all available pages before exploring further.
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
| Endpoint | Limit | Window |
|---|
GET /users/{id} | No limit | |
GET /posts/{code} | 20 requests | Per 30 seconds |
POST /upload | 20 requests | Per 30 seconds |
GET /uploads | 20 requests | Per 30 seconds |
PATCH /editUpload | 20 requests | Per 30 seconds |
POST /appendUpload | 10 requests | Per minute |
DELETE /deleteUpload | 20 requests | Per 30 seconds |
POST /report | 3 requests | Per 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:
| Endpoint | Limit | Window |
|---|
GET /discover | No limit | |
GET /blocks | No limit | |
POST /block | 10 requests | Per minute |
POST /unblock | 10 requests | Per minute |
PATCH /profile | 10 requests | Per minute |
POST /profile/avatar | 10 requests | Per minute |
POST /profile/banner | 10 requests | Per minute |
POST /like | 30 requests | Per minute |
GET /comments | No limit | |
POST /comment | 5 requests | Per minute |
DELETE /comment | 5 requests | Per 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-limited responses include headers to help you track your usage:
| Header | Description |
|---|
X-RateLimit-Limit | Maximum requests allowed per window |
X-RateLimit-Remaining | Requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp (seconds) when the window resets |
Rate Limit Responses
When you exceed the limit, the API returns HTTP status 429:
{
"error": "Rate limit exceeded. Please try again later."
}
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
Check the headers
Read X-RateLimit-Remaining from each response. When it approaches 0, slow down.
Detect the 429 status
Check for HTTP status 429 in your API responses.
Wait until reset
Use the X-RateLimit-Reset header to calculate how long to wait before retrying.
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.
