Google anunció el 4 de mayo de 2026 que la Gemini API incorpora webhooks, un sistema push que notifica en tiempo real la finalización de tareas largas y así evita el polling continuo (según el anuncio oficial de Google, 4/5/2026). Esta novedad está pensada para cargas agentic y de alto volumen, como Deep Research, generación de videos largos o el procesamiento de miles de prompts con la Batch API (según el anuncio oficial de Google, 4/5/2026). La implementación asegura entregas “at-least-once” y reintentos automáticos hasta 24 horas ante fallos (según el anuncio oficial de Google, 4/5/2026). En una frase: pasan de verificar estado con GET repetidos a recibir un POST en cuanto la tarea termina. A partir de hoy la función está disponible para todos los desarrolladores que usen Gemini API (según el anuncio oficial de Google, 4/5/2026).
¿Qué cambia para los desarrolladores?
Para quienes construyen agentes y pipelines de procesamiento, el cambio es práctico: en vez de mantener ciclos de polling que consumen CPU y ancho de banda, la API empuja una notificación HTTP POST cuando termina una tarea, reduciendo tráfico innecesario y latencia operativa. Google garantiza entregas “at-least-once” y ofrece reintentos automáticos por hasta 24 horas, lo que ayuda a manejar interrupciones temporales de red (según el anuncio oficial de Google, 4/5/2026). La configuración puede ser global, asegurada por HMAC, o dinámica por solicitud usando JWKS, lo que facilita enrutar trabajos puntuales a endpoints distintos sin cambiar la configuración del proyecto. Esto es especialmente útil para workflows en los que una operación puede tardar minutos u horas y donde el polling genera miles de llamadas redundantes. En la práctica, esperemos una reducción clara en el costo de operación y una respuesta más inmediata al usuario final.
¿Cómo impacta esto en el mercado argentino?
Para startups y equipos en Argentina la expectativa es positiva: menos polling significa menos costos de infraestructura y mejores tiempos de respuesta en productos que manejan contenido largo o lotes grandes. Empresas que procesan multimedia o analítica por lotes podrán orquestar jobs sin necesidad de escalar servidores que sólo atienden comprobaciones constantes. Sin embargo, la adopción local dependerrá de documentación en español y ejemplos con casos de uso regionales; sin eso, el onboarding se vuelve costoso para equipos pequeños. Además, dado que Google anuncia disponibilidad hoy (4/5/2026), los equipos argentinos que ya usan Gemini o la Batch API pueden probar la función de inmediato (según el anuncio oficial de Google, 4/5/2026). En resumen: la herramienta baja la barrera técnica, pero la adopción real en LATAM dependerá de soporte localizado y métricas públicas sobre fiabilidad.
Riesgos, seguridad y qué pedimos antes de adoptarlo masivamente
La implementación incluye headers para verificación (webhook-signature, webhook-id, webhook-timestamp) y opciones de seguridad (HMAC y JWKS), pero eso no exime de evaluar riesgos operativos y de privacidad. Google garantiza reintentos por hasta 24 horas, lo que reduce pérdidas por fallos temporales pero también implica que endpoints expuestos verán intentos repetidos de recepción (según el anuncio oficial de Google, 4/5/2026). Pedimos tres requisitos antes de adopciones amplias: métricas públicas sobre latencia y tasa de entrega fallida, documentación en español que detalle ejemplos y errores, y políticas de gobernanza con revisión humana cuando los agentes tomen decisiones relevantes. Mantenemos coherencia con nuestra postura previa sobre Google y la IA: apoyamos la innovación técnica, pero exigimos transparencia, documentación en español y redes de revisión humana antes de implementaciones a escala.
Como lectura práctica, Google publicó una guía y un Cookbook para integrar webhooks con ejemplos; los equipos deberían probar en entornos controlados y medir cuánto reduce el polling en su factura de infraestructura y en la experiencia de usuario.
