Rate Limits

API requests are rate-limited per account. During periods of high demand, conversions may remain queued until processing capacity becomes available. Heavy media jobs (video transcoding/compression, heavy audio) execute via our safe BullMQ capacity queue according to your plan's concurrency limits.

Limits are counted per account, or per IP address for requests with no account (the Guest row). An API key identifies your account — it does not add a second allowance, so one account with several keys still shares the allowance in this table, and an account without a key is limited at the base rate above.

On top of the per-endpoint limits, an account may make 5,000 requests per 15 minutesacross all endpoints together. That ceiling sits above every number in the table, so a plan's own allowance always binds first.

Each family of endpoints counts its own bucket, and both windows are enforced separately — a request is refused when either is exceeded. A refusal is always 429 with a Retry-After header.

Only the API requests row moves with your plan — Pro is 120 / minute and 2000 / hour, Business 300 / minute and 5000 / hour. The other three families are the same on every plan. Limits are counted per account: an API key identifies your account, it does not add an allowance of its own, and requests with no account fall back to the IP address.

On a server running in development mode these limits are not applied. They are enforced in production.

The per-endpoint limiters below send both families on every response, and the shared ceilings add the legacy family when they refuse. They report the same window — the difference is that the standard RateLimit-Reset is seconds from now, while the legacy X-RateLimit-Reset is an absolute epoch second. Read whichever family your client already understands.

# Standard family (IETF draft) — Reset is SECONDS FROM NOW
RateLimit-Limit: 120
RateLimit-Remaining: 87
RateLimit-Reset: 43

# Legacy family (kept for existing clients) — Reset is an ABSOLUTE epoch second
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1688712345

# On a refusal
Retry-After: 43

API conversions consume the same canonical processing quota and abide by the same file size rules as web conversions:

When you exceed a rate limit or queue capacity, the API returns 429 Too Many Requests or a queue-capacity status (QUEUE_FULL). Conversions execute according to server capacity, transitioning through queued → processing → completed. Best practices:

• Poll GET /api/conversions/:id while jobs are queued or processing
• Respect the Retry-After header on 429 rate limit responses
• Stay within your plan's batch limits (Guest: 2, Free: 5, Pro: 10, Business: 20)
• Upgrade your plan for higher file size limits and concurrent processing slots

Unauthenticated users have stricter limits: max 25 MB single file size, max 2 files per batch, 1 serial heavy job, and 5 queue limit. Sign in to increase your limits.

Authentication endpoints and password-reset requests are rate-limited to reduce abuse and protect account recovery.