Rate Limits & Request Limits
Concrete payload limits, per-token rate limiting, and how to discover limits programmatically.
LatentKit applies rate limits to protect the platform and ensure fair use across workspaces, and enforces concrete payload size limits at every layer of the edge.
Discover limits programmatically
GET /v1/me returns a limits object sourced from the same gateway settings that enforce them — SDKs and clients should pre-check payloads against it instead of discovering limits in production:
{
"limits": {
"max_request_body_bytes": 52428800,
"max_audio_bytes": 26214400,
"max_audio_url_bytes": 26214400,
"max_audio_seconds": null,
"queue_max_payload_bytes": 2097152,
"sync_idempotency_ttl_seconds": 86400,
"stt_job_result_ttl_seconds": 259200
}
}Request size limits (defaults)
| Limit | Default | Applies to |
|---|---|---|
max_request_body_bytes | 50 MB | Any single request body through the edge |
max_audio_bytes | 25 MB | Inline audio (base64, multipart file) on /v1/transcription, /v1/translation, /v1/audio |
max_audio_url_bytes | 25 MB | Remote audio fetched via audio.url |
max_audio_seconds | none | Audio duration cap (null unless the platform configures one) |
queue_max_payload_bytes | 2 MB | POST /v1/queue job payloads |
Numbers above are platform defaults; always trust the limits object from GET /v1/me for the deployment you are talking to.
- Oversized payloads return
413with a structured JSON error (REQUEST_TOO_LARGEfor the raw body,AUDIO_TOO_LARGEfor over-budget audio). The limit is enforced while the upload streams, so a missing or dishonestContent-Lengthheader does not bypass it — and the whole edge path (Cloudflare → nginx → app) is configured and continuously probed so the 413 is always JSON, never an HTML error page. - A
413is never retryable with the same payload; reduce the input size — or, for large audio, upload to your own storage and pass a signedaudio.urlinstead (see Audio and STT).
Rate limits
- Per-token rate limits apply at the edge before requests reach origin.
- Every
429carries aRetry-Afterheader (seconds). Honor it, then add jitter. - Rate-limited responses use the standard JSON error envelope with
code: "RATE_LIMITED"andretryable: true.
Best practices
- Run LatentKit calls server-side so you can centralize retries and logging
- Pre-check payload sizes against the
GET /v1/melimitsblock - Propagate
X-LK-Request-IDin your logs - Use
POST /v1/transcription/jobs(durable async jobs) for long audio instead of long synchronous requests - Send
Idempotency-Keyon transcription requests so retries can never double-bill — see Audio and STT
Plan limits
Workspace plans may enforce additional fair-use or billing limits beyond HTTP rate limits. Budget and plan errors return typed JSON — see Error handling.