Rate limits
Pace requests with separate buckets and clear retry headers.
Requests per key, per minute
| Class | Requests | Used for |
|---|---|---|
| Read | 300 | Retrieve videos, folders, events and account details |
| Write | 60 | Create, update or delete resources |
| Analytics | 60 | Views, downloads and current viewers |
| Upload | 30 | Create an upload target |
You will control request volume per API key and recover from a 429 without creating duplicate writes. Limits are token buckets that refill continuously.
Read the response headers
RateLimit-Limit is the per-minute capacity of the request's class. RateLimit-Remaining is the number of requests available now. RateLimit-Reset is the number of seconds until that bucket is full. Configured limits can change; the response headers are authoritative.
Creating a video from an upload spends a write request and an upload request. Creating another upload target also spends both. Analytics has a separate bucket from ordinary reads. Failed authentication is limited to twenty attempts per minute per client address.
Back off after a 429
Wait at least the number of seconds in Retry-After, add a small random delay to avoid synchronised retries, then try again. Reuse your original idempotency key for a POST retry. Avoid retrying in a tight loop or switching keys to evade a limit.
Upload allowances and clone limits are separate from request buckets. upload_quota_exceeded waits until the account's daily reset. clone_limit_reached covers 200 clones per rolling hour; clone_job_limit_reached means three jobs are still queued or running.