Rate limits

The public API (/api/v1/...) enforces a per-API-key quota. The current defaults are documented here — keep an eye on the response headers for the authoritative values, which override anything written below.

Default quota

• 600 requests per minute per API key, fixed-window. Configurable via the RATE_LIMIT_PER_MIN environment variable.
• The limit is enforced by ASP.NET’s RateLimiter middleware inside the application (before the endpoint handler runs) — not at a proxy layer. When an API key has no claim, the limiter falls back to the caller’s IP.

Response headers

Every response — both successful and rejected — carries:

Header	Meaning
X-RateLimit-Limit	Total requests allowed in the current window.
X-RateLimit-Remaining	Remaining requests in the current window.
X-RateLimit-Reset	Epoch seconds when the window rolls over.

Rejected responses (HTTP 429) also carry Retry-After (integer seconds).

429 body

{
  "type": "https://docs.tickr.coderise.cloud/errors/rate_limited",
  "title": "Too many requests",
  "status": 429,
  "detail": "rate_limited",
  "correlationId": "01HXYZ...."
}

The error code is rate_limited — encoded in the trailing segment of the type URL. See Errors for the full Problem Details shape.

Retry strategy

1. On 429, honor Retry-After before re-issuing the request.
2. Use exponential backoff with a cap of 60 seconds on 5xx.
3. Idempotent verbs (GET / PUT / DELETE) are safe to retry. POST is safe to retry only if your handler is idempotent — the server does not deduplicate.