Rate limits

Generation is rate limited per user (the user who owns the access token), not per workspace.

Limit	Value
Generations (all modalities)	60 per minute per user
Video generations	an additional 30 per minute per user

Video generations count against both limits. List, get, and estimate endpoints are not rate limited, and workflow runs are not currently subject to these generation limits.

Hitting a limit

When you exceed a limit, the execute request returns 429 RATE_LIMITED with a Retry-After header (in seconds):

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/problem+json

{ "type": "https://api.layer.ai/errors/RATE_LIMITED", "title": "Rate limited", "status": 429, "detail": "…" }

Wait for the Retry-After interval before retrying.

Which headers Layer sends

Header	Sent?	Notes
Retry-After	Yes, on 429	Seconds to wait. Honor it.
RateLimit / RateLimit-Policy (RFC 9331)	Not yet	Do not build against them.
X-RateLimit-*	Never	Legacy convention; Layer does not use it.

Note

There is no header to read your remaining quota from, so a client cannot self-throttle reactively — pace requests against the fixed limits above and back off on 429. The same facts are published machine-readably at /api/index.json under interfaces.rest.rate_limits.response_headers, so an agent can discover this without guessing.

Recommendations

• Spread bulk generation over time rather than bursting.
• Honor Retry-After; add jitter if you run many workers.
• Poll runs on the returned poll_interval_seconds (see Async jobs & polling) rather than tight-looping — polling reads aren’t the bottleneck, but a stampede of workers can be.