O Google lançou webhooks event-driven pra Gemini API, eliminando o polling pra jobs longos através de três famílias de endpoints: Batch (succeeded / cancelled / expired / failed), Interactions (requires_action / completed / failed / cancelled), e Video Generation (video.generated). A implementação segue a spec Standard Webhooks — assinatura HMAC-SHA256 pra webhooks estáticos (nível projeto), JWT assimétrico (RS256) via JWKS pra webhooks dinâmicos (por request), com headers `webhook-signature`, `webhook-id`, e `webhook-timestamp`. Entrega at-least-once, janela de retry de 24h com backoff exponencial. Janela anti-replay recomendada: rejeitar payloads com mais de cinco minutos de idade.
Os dois modos de configuração importam. *Estático*: configurado a nível projeto via uma WebhookService API, dispara pra qualquer event match dentro desse projeto, usa um segredo compartilhado pra validação HMAC. *Dinâmico*: override em tempo de request com um payload `webhook_config`, usa JWT assimétrico assinado pelas chaves do Google (verificável em `https://generativelanguage.googleapis.com/.well-known/jwks.json`). O modo dinâmico também suporta um campo `user_metadata` pra roteamento — a metadata viaja de ida e volta no payload do webhook, então um único endpoint pode fazer fan-out por tenant, usuário, ou workflow sem armazenar estado de job-ID separadamente. Os payloads são intencionalmente finos: snapshots de status com ponteiros como `output_file_uri` (Batch) ou `file_id` e `video_uri` (Video), não saídas cruas. Servidores respondem `2xx` imediatamente e processam async pra evitar ciclos de retry. O header `webhook-id` te dá a primitiva de deduplicação.
Pra contexto de ecossistema, isso põe a Gemini API em paridade-plus em entrega de events. A Batch API da OpenAI e os Message Batches da Anthropic ambos rodam async com status que você atualmente *polla* — uma corrida batch de 24h significa polling em cronograma queimando orçamento de requests esperando a completação. Webhooks invertem isso: sua aplicação dorme até o Google notificar. Pra geração de vídeo especificamente (cargas estilo Veo podem rodar dezenas de segundos a minutos por request), polling é ainda mais perdulário. O split estático-vs-dinâmico é bem pensado: estático pra "tenho um time rodando batch jobs, me dá um segredo pra verificar todos", dinâmico pra "sou um SaaS rodando cargas Gemini multi-tenant e preciso que cada webhook de tenant aterrisse no seu endpoint isolado com sua metadata anexada". Essa é uma forma de capacidade útil de copiar se você constrói algo similar.
Leituras práticas. Se você roda jobs Gemini Batch ou de vídeo e atualmente polla, muda — isso economiza chamadas API, reduz latência de cauda na detecção de completação, e é estruturalmente mais limpo. A janela anti-replay de 5 minutos mais dedup por `webhook-id` significa que seu handler de webhook precisa de uma camada de idempotência (a maioria já tem). Pra devs multi-tenant, webhooks dinâmicos com `user_metadata` é o padrão certo — não tente mapear webhooks estáticos entre tenants parseando job IDs. Compare seu overhead atual de polling OpenAI / Anthropic e decida se vale a pena pressionar esses provedores a lançar cobertura Standard Webhooks também. O sinal não é "webhooks são novos"; webhooks são velhos. O sinal é que APIs IA finalmente estão recebendo tratamento Standard Webhooks, o que significa que infraestrutura agent-and-batch pode ser construída com as mesmas primitivas operacionais que o resto do seu stack.