Rate Limits

CortexVigil enforces per-app rate limits to keep the platform responsive for everyone.

Limit Configuration

Each External App carries a rate_limit_per_min value, set when the app is created and editable from Admin → External Apps.

The limit applies independently to REST and MCP traffic — both share the same counter (i.e. an app with 60/min cannot do 60 REST + 60 MCP, only 60 combined).

How Limits Are Counted

Counters are tracked in Redis using a fixed-window strategy over a rolling 60-second window. Each successful authenticated request increments the counter for that app's bucket.

Unauthenticated requests (rejected with 401) do NOT count against the limit.

429 Response

When the limit is exceeded the server responds:

HTTP/1.1 429 Too Many Requests
Retry-After: 23
Content-Type: application/json

{
  "detail": "rate_limit_exceeded",
  "limit_per_min": 60,
  "retry_after_seconds": 23
}

Always respect Retry-After. It is an integer number of seconds to wait before the next request.

Recommended Client Behaviour

• Implement exponential backoff with Retry-After as the floor (never retry sooner).
• Batch list operations using the limit and cursor query parameters rather than polling.
• Use webhooks (where available) instead of polling for event freshness.

Bursting

Short bursts above the per-minute limit are tolerated up to ~20% over the configured rate for a single 5-second window. Sustained over-limit traffic is rejected.

Requesting a Higher Limit

Contact your account manager or open a ticket from Admin → Support with:

• App ID
• Current rate_limit_per_min
• Requested limit
• Use case and expected sustained QPS