Google voegt webhooks toe aan de Gemini API: minder polling, snellere agent-workflows

Google heeft “event-driven webhooks” toegevoegd aan de Gemini API. Daarmee kunnen lange AI-taken – denk aan batchverwerking, deep research of video-generatie – automatisch een HTTP POST naar jouw server sturen zodra een job klaar is, in plaats van dat je continu moet pollen. Google beschrijft het als een push-systeem dat frictie en latency in agentic applicaties verlaagt (Google). Voor de technische details verwijst Google naar de Gemini API Webhooks-documentatie.

Waarom dit belangrijk is voor developers

Polling is simpel, maar duur en onhandig: je schiet steeds opnieuw dezelfde GET-request af “is het al klaar?”. Dat kost API-calls, maakt je backend rommelig (timers, backoff, retries) en zorgt dat je workflow pas “wakker” wordt bij de volgende poll. Met webhooks draait het om: de API meldt zich zelf zodra er een statuswijziging is.

Dat past bij de trend dat AI-systemen steeds meer agentic worden: meerdere stappen, tool-calls, wachttijden en soms duizenden taken in parallel. Op AI-Feiten schreven we eerder al hoe realtime architectuur (zoals WebRTC) draait om het minimaliseren van wachttijd en jitter bij spraak-AI (OpenAI’s low-latency spraakstack, gebaseerd op OpenAI’s eigen engineering-post). Webhooks zijn de “asynchrone” tegenhanger: niet sneller rekenen, maar wél sneller schakelen.

Zo werkt Gemini API Webhooks (in hoofdlijnen)

Volgens Google kun je webhooks projectbreed instellen, of per request overriden om specifieke jobs naar een andere endpoint te routeren (Google). De implementatie volgt de Standard Webhooks-spec, en elke request wordt ondertekend met headers zoals webhook-signature, webhook-id en webhook-timestamp. Dat helpt tegen replay attacks en maakt idempotent verwerken haalbaar.

Verder belooft Google “at-least-once delivery” met automatische retries tot 24 uur. Dat is fijn, maar het betekent ook dat je webhook-consumer duplicaten moet kunnen verwerken (bijvoorbeeld door webhook-id op te slaan).

Wat verandert er voor agentic workflows en de Batch API?

Google noemt expliciet scenario’s zoals long-running agentic apps en hoge-volume processing via de Batch API (Google). Praktisch betekent dit dat je pipeline simpeler wordt:

• Je start een job en slaat een job-id + context op.
• Je wacht op de webhook callback (in plaats van een poll-loop).
• Je triggert de volgende stap: opslaan, samenvatten, evalueren of doorzetten naar je product.

Voor teams die al bezig zijn met Gemini in productiviteit of documentflows is dit extra relevant. Denk aan de recente mogelijkheden om met Gemini direct documenten/PDF’s te genereren en in workflows te plakken (Gemini maakt nu direct bestanden).

Wat betekent dit (en waar moet je op letten)?

Dit is vooral een DX-upgrade: minder verspilde calls, minder “wachten op de volgende poll” en makkelijker schaalbare orchestratie. Tegelijk moet je je webhook-endpoint serieus beveiligen (HMAC/JWKS, rate limiting, logging) en duplicaten goed afhandelen.

De kans is groot dat dit soort event-driven integraties snel standaard worden, zeker nu AI-workloads groter en langduriger worden (denk aan chip- en infra-ontwikkelingen waar we eerder over schreven, zoals nieuwe TPU’s voor agents: TPU 8t/8i). Voor developers is de boodschap helder: bouw je AI-workflows alsof ze distributed systems zijn — en webhooks zijn daarbij een logische bouwsteen.