LatentKit

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)

LimitDefaultApplies to
max_request_body_bytes50 MBAny single request body through the edge
max_audio_bytes25 MBInline audio (base64, multipart file) on /v1/transcription, /v1/translation, /v1/audio
max_audio_url_bytes25 MBRemote audio fetched via audio.url
max_audio_secondsnoneAudio duration cap (null unless the platform configures one)
queue_max_payload_bytes2 MBPOST /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 413 with a structured JSON error (REQUEST_TOO_LARGE for the raw body, AUDIO_TOO_LARGE for over-budget audio). The limit is enforced while the upload streams, so a missing or dishonest Content-Length header 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 413 is never retryable with the same payload; reduce the input size — or, for large audio, upload to your own storage and pass a signed audio.url instead (see Audio and STT).

Rate limits

  • Per-token rate limits apply at the edge before requests reach origin.
  • Every 429 carries a Retry-After header (seconds). Honor it, then add jitter.
  • Rate-limited responses use the standard JSON error envelope with code: "RATE_LIMITED" and retryable: true.

Best practices

  • Run LatentKit calls server-side so you can centralize retries and logging
  • Pre-check payload sizes against the GET /v1/me limits block
  • Propagate X-LK-Request-ID in your logs
  • Use POST /v1/transcription/jobs (durable async jobs) for long audio instead of long synchronous requests
  • Send Idempotency-Key on 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.

On this page