YouTube API Rate Limit
How YouTube Data API quota actually works — it’s not a request-count limit, it’s a points budget.
By André LugThe YouTube Data API v3 has no requests-per-minute rate limit. Each Google Cloud project gets 10,000 shared quota units per day — with operations costing from about 1 unit for list reads to 400 for captions.insert — plus separate allowances of 100 calls per day each for videos.insert and search.list. Everything resets at midnight Pacific Time.
"Rate limit" is the wrong mental model for the YouTube Data API v3. There is no simple requests-per-minute ceiling — instead, most endpoints draw from a shared daily points pool where different operations cost different amounts, while video uploads and searches are capped by their own separate daily allowance that has nothing to do with that pool. Everything resets on a fixed clock, not a rolling window from your last request.
The quota model, not a rate limit
Every Google Cloud project gets a default 10,000 units per day, shared across nearly every endpoint, plus a separate, fixed 100 calls per day each for videos.insert and search.list, charged at 1 unit per call inside their own bucket rather than the shared pool. All of it resets at midnight Pacific Time, per Google's quota documentation. A project can exhaust its upload allowance while the general 10,000-unit pool sits almost untouched — the two are tracked completely independently.
Why is this easy to misdiagnose in production?
Costs across the shared pool are not uniform — cheap *.list reads run about 1 unit, while write operations like captions.insert (400 units) or most other insert/update/delete calls (typically 50 units) cost much more. A team checking only its overall unit consumption can see plenty of headroom and still have uploads failing with a 403 quotaExceeded, because the number that actually ran out was the small, separate upload bucket — not the general quota. We cover this exact failure mode in Fixing YouTube API 403 quotaExceeded.
How do you design an integration around a points budget?
Check Google Cloud Console's quota metrics for real consumption by operation, not a guess. Cache search.list results or replace them with cheaper *.list calls against known IDs where possible — that allowance is only 100 calls a day and shared across your whole project. Deduplicate retry logic so a client-side timeout does not trigger a second videos.insert against the same 100-upload ceiling. See YouTube API Quota Cost per Upload for the exact per-upload accounting.
How does PostGate help here?
PostGate's structured error envelope tags a YouTube quota rejection distinctly and marks it for appropriate retry behavior, so an integration does not keep hammering an exhausted allowance. Because PostGate operates its own YouTube API project for hosted connections, quota planning and increase requests happen at the platform level — see the YouTube platform guide for how that fits into PostGate's multi-tenant delivery model.
Frequently asked questions
What is the YouTube API daily quota?
Every Google Cloud project gets a default 10,000 units per day, shared across nearly every endpoint, plus a separate, fixed 100 calls per day each for videos.insert and search.list — charged at 1 unit per call inside their own bucket rather than the shared pool. All of it resets at midnight Pacific Time.
How much do different YouTube API operations cost?
Costs across the shared pool are not uniform — cheap *.list reads run about 1 unit, while write operations like captions.insert (400 units) or most other insert/update/delete calls (typically 50 units) cost much more.
Why are my uploads failing while I still have quota left?
Because the small, separate upload bucket ran out — not the general quota. A team checking only its overall unit consumption can see plenty of headroom and still have uploads failing with a 403 quotaExceeded, since videos.insert draws from its own 100-calls-per-day allowance tracked independently of the shared pool.
How can I reduce YouTube API quota usage?
Check Google Cloud Console’s quota metrics for real consumption by operation rather than guessing. Cache search.list results or replace them with cheaper *.list calls against known IDs — that allowance is only 100 calls a day, shared across your whole project. And deduplicate retry logic so a client-side timeout does not trigger a second videos.insert against the same 100-upload ceiling.
