Google ने Gemini API के लिए event-driven webhooks जारी किए हैं, तीन endpoint families में long-running jobs के लिए polling को ख़त्म करते हुए: Batch (succeeded / cancelled / expired / failed), Interactions (requires_action / completed / failed / cancelled), और Video Generation (video.generated)। Implementation Standard Webhooks spec का अनुसरण करता है — static (project-level) webhooks के लिए HMAC-SHA256 signing, dynamic (per-request) webhooks के लिए asymmetric JWT (RS256) JWKS के माध्यम से, `webhook-signature`, `webhook-id`, और `webhook-timestamp` headers के साथ। At-least-once delivery, exponential backoff के साथ 24-hour retry window। अनुशंसित replay-attack window: पाँच मिनट से पुराने payloads अस्वीकार करें।
दोनों configuration modes मायने रखते हैं। *Static*: WebhookService API के माध्यम से project level पर configured, उस project के तहत किसी भी matching event के लिए fire करता है, HMAC validation के लिए shared secret का उपयोग करता है। *Dynamic*: request time पर `webhook_config` payload के साथ override करता है, और Google की keys से signed asymmetric JWT का उपयोग करता है (`https://generativelanguage.googleapis.com/.well-known/jwks.json` पर verifiable)। Dynamic mode routing के लिए `user_metadata` field भी सपोर्ट करता है — metadata webhook payload में वापस round-trip करती है, इसलिए एक endpoint बिना job-ID state अलग से store किए tenant, user, या workflow द्वारा fan-out कर सकता है। Payloads जानबूझकर पतले हैं: pointers जैसे `output_file_uri` (Batch) या `file_id` और `video_uri` (Video) के साथ status snapshots, raw outputs नहीं। Servers `2xx` तुरंत respond करते हैं और retry cycles से बचने के लिए asynchronously process करते हैं। `webhook-id` header आपको deduplication primitive देता है।
Ecosystem context के लिए, यह Gemini API को event delivery पर parity-plus तक लाता है। OpenAI की Batch API और Anthropic की Message Batches दोनों async चलती हैं, status के साथ जिसे आप अभी *poll* करते हैं — 24-hour batch run का मतलब है schedule पर polling और completion के इंतज़ार में request budget जलाना। Webhooks उसे उलट देते हैं: आपका application तब तक सोता है जब तक Google notify नहीं करता। Video generation के लिए विशेष रूप से (Veo-style workloads प्रति request दसियों सेकंड से मिनट तक चल सकते हैं), polling और भी बर्बादी है। Static-vs-dynamic split अच्छी तरह सोचा गया: static "मेरे पास batch jobs चलाने वाली एक team है, मुझे सबको verify करने के लिए एक secret दो" के लिए, dynamic "मैं multi-tenant Gemini workloads चलाने वाला SaaS हूँ और मुझे चाहिए कि हर tenant का webhook अपने isolated endpoint पर अपनी metadata के साथ उतरे" के लिए। यह उपयोगी capability shape है जिसे copy करना सार्थक है अगर आप कुछ similar बना रहे हैं।
व्यावहारिक पठन। अगर आप Gemini Batch या video jobs चलाते हैं और वर्तमान में poll करते हैं, switch करें — यह API calls बचाता है, completion detection पर tail latency कम करता है, और संरचनात्मक रूप से क्लीनर है। 5-minute replay window plus `webhook-id` dedup का मतलब है कि आपके webhook handler को idempotency layer चाहिए (अधिकांश के पास पहले से है)। Multi-tenant builders के लिए, `user_metadata` के साथ dynamic webhooks सही pattern है — tenants में static webhooks को job IDs parse करके map करने की कोशिश न करें। अपने वर्तमान OpenAI / Anthropic polling overhead की तुलना करें और तय करें कि क्या उन providers को भी Standard Webhooks coverage ship करने के लिए धकेलना सार्थक है। संकेत यह नहीं है कि "webhooks नए हैं"; webhooks पुराने हैं। संकेत यह है कि AI APIs को आख़िरकार Standard Webhooks treatment मिल रहा है, जिसका मतलब है कि agent-and-batch infrastructure आपके stack के बाक़ी हिस्से जैसे ही operational primitives से बनाई जा सकती है।