Sync Labs API rate limit: 100 per minute, and Sume headers

Sync Labs limits POST /v2/generate to 100 requests per minute and GET /v2/generate/* to 600 requests per minute, and returns a 429 when you exceed either. Sume documents a requests-per-minute budget per plan instead of those two numbers, and tells you to read the ratelimit-remaining header and back off on retry-after rather than counting requests yourself.

Sync facts are from its rate-limit guide; Sume facts from Authentication, read 2026-10-01.

What are the Sync Labs limits?

Limits are enforced per authenticated user when an API key is present, and per IP address otherwise. Separately, concurrency (generations in PENDING or PROCESSING) is set by plan and also returns 429 when exceeded. The guide advises against retrying a 429 in a tight loop and recommends exponential backoff.

What does Sume send back?

Every response carries rate-limit headers, and a 429 names the budget in error.details.scope (read or write).

How should a client handle a 429?

Wait for retry-after seconds, then retry. For submits, keep the same idempotency key so a retry cannot create a second paid job. Request rate is not generation capacity: how many jobs run at once is governed by the plan's concurrency limit, reported in generation_limits. A full queue is a different failure, 429 queue_full; see 429 vs 503.

Do polling reads count against the same budget?

The docs describe separate read and write budgets, and say the headers describe whichever budget the current request spent from. A jobs_status poll over MCP spends no write budget. Trust ratelimit-limit on the response for the deployment you are talking to.