Cota da API do YouTube excedida

Todo projeto do Google Cloud usando a YouTube Data API v3 recebe uma alocação padrão de 10.000 unidades por dia, combinadas, para todo endpoint exceto dois — mais uma alocação fixa e separada de 100 chamadas por dia cada para videos.insert e search.list, cobradas a 1 unidade por chamada dentro do próprio bucket, e não do pool compartilhado. Tudo reseta à meia-noite no horário do Pacífico, não numa janela móvel de 24 horas a partir da sua última requisição, segundo a documentação de cota do Google. Toda chamada contra o pool compartilhado de 10.000 unidades consome o mesmo total no nível do projeto, independente de qual usuário final ou canal está agindo em nome de quem — então esgotar esse pool é um problema no nível do projeto mesmo que só a atividade de um cliente o tenha causado — mas um projeto pode separadamente ficar sem sua cota de upload ou busca enquanto o pool principal está intocado, exatamente o tipo de divisão que torna esse erro confuso de diagnosticar.

Os custos dentro do pool compartilhado não são uniformes. Operações de leitura simples (a maioria das chamadas *.list) são baratas, tipicamente uma única unidade cada. Operações de escrita — insert, update, delete — custam bem mais: captions.insert custa 400 unidades, por exemplo, e a maioria das outras chamadas de insert/update/delete em playlists, comentários, inscrições e recursos de canal custa 50. O Google publica a tabela completa de custo por operação (e uma calculadora de cota) no link acima; trate qualquer número repetido num fórum como uma captura que pode estar desatualizada, e confira a tabela publicada atual antes de planejar em cima dela.

videos.insert — a operação por trás de todo upload programático de vídeo — e search.list consomem de um bucket fixo próprio de 100 chamadas por dia, separado do pool geral. Isso nem sempre foi assim, e a história importa se você está cruzando um post antigo de fórum ou blog com o comportamento atual: durante anos, uma única chamada de videos.insert custava sozinha cerca de 1.600 unidades do pool compartilhado, então um projeto padrão de 10.000 unidades sustentava só um punhado de uploads por dia antes de se esgotar, mesmo com zero outra atividade de API. O Google baixou esse custo por chamada para cerca de 100 unidades e depois moveu tanto videos.insert quanto search.list para um bucket de cota totalmente separado — em dezembro de 2025, veja as entradas datadas no histórico de revisões da YouTube Data API do Google para saber exatamente quando cada mudança entrou no ar.

O efeito prático hoje: atividade geral pesada de API (chamadas de lista, leituras de metadados, gestão de playlist) não consegue mais esgotar a sua capacidade de fazer upload de vídeo, e fazer upload de vídeo não consegue mais esgotar chamadas de leitura sem relação. Mas o teto de 100 chamadas por dia em uploads e buscas é, ele mesmo, um limite duro, e um projeto publicando em volume real ainda pode bater nele — um time provisionando para mais de 100 uploads ou mais de 100 buscas num dia esgota esse bucket específico e vê exatamente o mesmo erro 403 quotaExceeded, mesmo com o pool geral de 10.000 unidades intocado.

Essa divisão é a fonte mais comum de diagnóstico errado em produção: um time checa o consumo geral de unidades, vê bastante folga no pool compartilhado e não entende por que os uploads continuam falhando — porque o número que de fato se esgotou foi a alocação separada e bem menor de upload, não a cota geral.

• Confira as métricas de cota do Google Cloud Console do seu projeto para ver o consumo real de unidades ao longo do tempo e quais operações específicas estão gerando isso — e confira os buckets de videos.insert e search.list separadamente do pool geral, já que são rastreados e esgotados de forma independente. Não chute.
• Procure chamadas evitáveis contra os buckets pequenos e de tamanho fixo: chamadas repetidas de search.list que poderiam ser substituídas por resultados em cache, notificações no estilo PubSub, ou uma chamada *.list mais barata com IDs conhecidos; loops de polling que rechecam o mesmo recurso com muito mais frequência do que o dado realmente muda; ou tentativas duplicadas de upload disparadas por lógica de retry no lado do cliente que não checa se o upload original de fato deu certo antes de tentar de novo.
• Confirme que você não está rodando acidentalmente requisições caras em cota contra o canal de cada usuário numa agenda fixa (um job noturno de "atualizar tudo" é um clássico matador de cota) quando uma abordagem orientada a eventos usaria uma fração das unidades.

O Google não concede cota acima do padrão automaticamente. Os pedidos passam pelo processo de Auditoria e Extensão de Cota da API Services do YouTube, e qualquer pedido de cota além da alocação padrão exige completar uma auditoria de conformidade primeiro — isso não é reservado para pedidos incomumente grandes, é o caminho padrão para todo aumento. Um pedido que costuma ser aprovado geralmente inclui:

• Um número específico e calculado de unidades adicionais, ligado a uma composição real de operações esperadas por dia (uploads, chamadas de lista etc.) — não um número redondo escolhido por parecer suficiente.
• Uma descrição clara do que a sua aplicação faz e quem a usa, já que descrições de caso de uso genéricas ou vagas são um motivo comum de reprovação ou demora longa na revisão.
• Evidência de que você já otimizou o uso evitável — os revisores são mais receptivos a um pedido de um projeto que claramente não está desperdiçando cota em chamadas desnecessárias.
• Uma auditoria de conformidade concluída contra os Termos de Serviço da API do YouTube; questões de conformidade não resolvidas bloqueiam um aumento independente de quão bem justificado o número esteja.

Espere essa revisão levar tempo de verdade, e peça o aumento bem antes de um lançamento, não durante ele.

O envelope estruturado de erro do PostGate expõe a rejeição de cota do YouTube como um erro distinto, marcado por plataforma, em vez de uma falha genérica, e o classifica corretamente para o comportamento de retentativa, para que a sua integração não martele uma cota já esgotada. Como o PostGate opera o próprio projeto de API do YouTube em seu nome para conexões hospedadas, o planejamento e os pedidos de aumento de cota são tratados no nível da plataforma — veja os guias de plataforma para entender como o app provedor e o modelo de cota do YouTube se encaixam na entrega multi-tenant do PostGate.