PLEXICHATNarrative Docs
Rate Limits
Guides, route-group overviews, and live schema entry points for the Plexichat backend.
REST http://api.plexichat.com/api/v1Gateway ws://api.plexichat.com/gatewayVersion a.1.0-49
Rate Limits
Plexichat applies multiple layers of request protection to keep the API stable under normal traffic and abuse conditions.
Default Buckets In Code
The backend defines these default baseline limits in src/core/ratelimit/config.py.
This page now reflects the current runtime configuration:
| Scope | Default |
|---|---|
| global | 50 requests per 1 second, burst 10 |
| per-user | 70 requests per 60 seconds, burst 20 |
| per-IP | 70 requests per 60 seconds, burst 10 |
Servers can override these values through configuration.
Route-Level Examples
The code also defines stricter limits for sensitive or high-volume routes:
| Route pattern | Default |
|---|---|
DELETE /channels/{id}/messages/{msg_id} | 5 requests per 5 seconds, burst 2 |
DELETE /channels/{id}/messages/{msg_id}/reactions/{emoji} | 1 requests per 0.25 seconds, burst 1 |
DELETE /servers/{id} | 1 requests per 60 seconds, burst 0 |
GET /admin/database/pool-health | 120 requests per 60 seconds, burst 20 |
GET /admin/telemetry/stats | 120 requests per 60 seconds, burst 20 |
GET /admin/ui-dashboard | 120 requests per 60 seconds, burst 20 |
GET /channels/{id}/messages | 10 requests per 10 seconds, burst 5 |
GET /qr | 20 requests per 60 seconds, burst 5 |
GET /relationships/@me | 100 requests per 60 seconds, burst 20 |
GET /servers/{id} | 20 requests per 10 seconds, burst 10 |
GET /servers/{id}/channels | 100 requests per 60 seconds, burst 20 |
GET /users/@me | 30 requests per 60 seconds, burst 10 |
PATCH /channels/{id}/messages/{msg_id} | 5 requests per 5 seconds, burst 2 |
PATCH /users/@me | 2 requests per 60 seconds, burst 0 |
POST /auth/2fa | 5 requests per 60 seconds, burst 2 |
POST /auth/login | 5 requests per 60 seconds, burst 0 |
POST /auth/register | 3 requests per 60 seconds, burst 0 |
POST /channels/{id}/messages | 5 requests per 5 seconds, burst 3 |
POST /feedback | 5 requests per 3600 seconds, burst 0 |
POST /media/upload | 10 requests per 60 seconds, burst 2 |
POST /relationships | 5 requests per 60 seconds, burst 2 |
POST /relationships/block | 10 requests per 60 seconds, burst 5 |
POST /servers | 10 requests per 60 seconds, burst 2 |
POST /telemetry | 30 requests per 60 seconds, burst 5 |
POST /webhooks | 5 requests per 60 seconds, burst 2 |
POST /webhooks/{id}/{token} | 5 requests per 2 seconds, burst 5 |
PUT /channels/{id}/messages/{msg_id}/reactions/{emoji} | 1 requests per 0.25 seconds, burst 1 |
THUMBNAIL_GEN | 60 requests per 60 seconds, burst 10 |
Runtime Policy Snapshot
| Setting | Current value |
|---|---|
| Bot multiplier | 1.5x |
| Webhook multiplier | 1x |
| Admin bypass | enabled |
| Internal bypass | enabled |
What Clients Should Expect
- limits may be applied globally, per user, per IP, or per route/resource
- a server can tune limits away from the code defaults
- bots and feature tiers may receive different multipliers depending on server policy
- admin and internal bypass behavior is configurable and should not be assumed by public clients
Typical Response Signals
Rate-limited requests return 429 Too Many Requests and may include standard rate-limit headers plus retry metadata in the error response.
Client Recommendations
- back off on
429instead of retrying immediately - use pagination and caching to reduce repeated reads
- batch operations where supported
- keep message send loops and reaction spam under control
- prefer gateway events over high-frequency polling