Grand BladeMedia Start a conversation

Guides / YouTube API

YouTube API quota: two buckets, not one

Justin Gim Ho Cheung, Creative Director · Published · 8 min read

Tested on: Three channels sharing one Cloud project

TL;DR

  • Two methods get their own daily limit: videos.insert and search.list, each 100 calls a day at 1 unit a call. Google says more per-method buckets are coming.
  • Almost everything else shares one pool of 10,000 units a day, per project. Thumbnails, playlist edits and any later videos.update, such as a schedule set after upload, are paid from it.
  • When the pool shows spent, look for a polling consumer first.

The old model, one upload costing 1,600 units, still sits in the AI-generated summary at the top of Google’s own cost page. We held that model once, and it gave us a wrong diagnosis. This is what we should have had on Sep 6, 2026, checked against the page on Oct 2, 2026.

Step 1: Read the page, not your memory

On Oct 2, 2026 we read Google’s quota cost page line by line. A project gets, by default, 100 search.list calls, 100 videos.insert calls and 10,000 units a day for all other endpoints, reset at midnight Pacific Time.

Google’s revision history dates the change. On Dec 4, 2025 it updated its docs for an upload cost falling from about 1,600 units to about 100. On Jun 1, 2026 it moved videos.insert and search.list into buckets of their own, the start of a more granular system. On Jun 3, 2026 a new method, videos.batchGetStats, got a bucket too. The cost table does not list it. So “two buckets” describes the table on Oct 2, 2026, not a promise. Our Sep 6, 2026 diagnosis used a model two revisions out of date.

Our notes from that day also had liveChatMessages.list at 5 units. That figure was not on the cost page. The Internet Archive’s copy from Sep 6, 2026 (marked last updated Sep 4) has no live streaming rows at all, and the Sep 15, 2026 version lists them at 1 unit. We could not trace our 5. Treat chat-polling math from before Sep 15, 2026 with suspicion.

Step 2: Put each call in its bucket

Cost per call on Google’s quota cost page, read Oct 2, 2026; the page says last updated Sep 15, 2026.
CallBucket and limitUnits per call
videos.insertOwn: 100 calls a day1
search.listOwn: 100 calls a day1
videos.updateShared: 10,000 units a day50
thumbnails.setShared: 10,000 units a day50
playlistItems.insertShared: 10,000 units a day50
comments.insertShared: 10,000 units a day50
videos.list, channels.list, playlistItems.listShared: 10,000 units a day1
captions.listShared: 10,000 units a day50
liveChatMessages.listShared: 10,000 units a day1

Step 3: Count what your pipeline spends

Uploads are cheap. The work around an upload is not. Take a pipeline that uploads a video, sets a thumbnail, schedules it with a later update and adds it to a playlist. That is one insert in its own bucket, plus 50, 50 and 50 units from the pool: 150 units. At 10,000 units a day, the pool runs dry after 66 such uploads, since 66 times 150 is 9,900. The 100-call insert limit never gets a turn.

You can skip the update. The videos.insert reference lists status.publishAt among the properties you can set, and the videos resource page says it works only on a private video that has never been published, so the schedule rides on the upload call. A thumbnail and a playlist add then cost 100 pool units, and the pool lasts at most 100 uploads, about when the insert bucket runs out. But that needs the publish time at upload. Pick the slot after a check, and you still pay the 50-unit update.

This is arithmetic on Google’s docs, not a record of what our pipelines did.

Step 4: When the pool is spent, find the poller

All three of our channels share one Cloud project, so they share one pool. Google assigns the allocation to the project, not to a channel. One careless loop can empty the pool for every tool we run.

On Sep 6, 2026 one did. A chat-polling consumer in a stream co-host app had been reading live chat through the Data API and drained the units. Scheduling and thumbnails broke, because videos.update and thumbnails.set draw from the pool. Uploads kept working, because they have their own bucket.

That pattern is the signature: uploads fine, everything else failing. We took the polling off the shared pool. Our notes from that day estimated use afterward at roughly 1,000 to 2,000 units a day. That was a same-day estimate, not a measurement over weeks, and is not re-checked against current docs.

Google’s own advice for chat is liveChatMessages.streamList. It pushes new messages instead of being polled, which Google says helps you stay under quota. On liveChatMessages.list, wait the pollingIntervalMillis each response returns, and pass back its nextPageToken.

Step 5: Decide whether you need more

Google’s audit page says anything beyond the default allocation requires a compliance audit, started through its Audit and Quota Extension Form. That is a process, not a toggle, so do the Step 3 arithmetic before you start it.

For us it is unnecessary. Uploads sit in their own bucket at 100 a day, and our estimated pool use is a fraction of 10,000. The lesson we keep: never quote a quota cost from memory.

Run it yourself

  • Fetch the cost page on the day you plan. Read the table, not a summary line or your notes.
  • Write down each method’s bucket: insert, search, or the shared pool.
  • Multiply pool units per upload (thumbnail, playlist add, any schedule update) by uploads per day. Compare with 10,000.
  • List every consumer on the project. Give each a daily self-cap and a unit log.
  • When the pool shows spent, check the pollers before you blame uploads.
  • Date your notes, and re-read the cost page and revision history monthly.

Sources

Start with a channel teardown.

One written audit of one channel or pipeline, with specific fixes. I read every request myself.

Request a teardown