Rate Limiting

Outcron applies rate limiting to API requests to protect the service from abuse and ensure fair usage across all tenants.

How It Works

Rate limiting uses Redis-backed GCRA (Generic Cell Rate Algorithm) when Redis is configured. Without Redis, single-node deployments use per-process in-memory token buckets and still honor observe and enforce modes.

Limits can vary by request category. Authentication, signup, public billing, contact submissions, and high-cost authenticated operations may have different budgets than ordinary API reads. Multi-instance deployments should use Redis for coherent limits; otherwise each process has its own budget.

Response Headers

When rate limiting is active for the deployment, API responses include rate limit information when the active backend can report it:

When rate limited, the response also includes:

Rate Limit Response

When you exceed the limit, the API returns 429 Too Many Requests:

{
      "error": "rate limit exceeded",
      "code": "rate_limited"
    }
    

Wait for the duration specified in the Retry-After header before retrying.

Deployments with rate limiting disabled or running in observe-only mode may not emit every rate-limit header on allowed requests. Redis-backed deployments provide the most precise remaining/reset data; in-memory deployments provide per-process advisory values. A 429 response includes Retry-After.

The Prometheus /metrics listener is separate from the API router and is not governed by platform rate limiting.

Best Practices

• Monitor the X-RateLimit-Remaining header to avoid hitting limits.
• Implement exponential backoff when receiving 429 responses.
• Use API keys with appropriate scoping rather than sharing credentials across many clients.
• For high-throughput integrations, contact support about limit adjustments.