Webhook o getUpdates: ¿es una migración del bot u otra reparación?
Compara receptores por cola, confirmación, propiedad del endpoint y corte antes de estimar una migración de Telegram.
Señales que conviene observar
- El receptor actual y el objetivo están identificados
- La cola pendiente y el offset tienen un destino acordado
- Corte, rollback, secreto y aceptación tienen responsables
Cambiar un bot entre webhook y getUpdates modifica el receptor y el estado de entrega; no es una tarea genérica de «mover el bot». Antes de cotizar, identifica receptor activo, cola pendiente, offset o estado del webhook, tipos de Update, verificación, momento de corte y responsable del rollback. Bot API es la interfaz de programación de Telegram; CRM es gestión de relaciones con clientes.
La comparación sirve a un consultor que revisa grupos autorizados. La señal comercial fuerte nombra origen, destino y ventana. «Webhook va lento, pasadnos a polling» es una hipótesis, y llamar migración a cada timeout crea un alcance equivocado.
La respuesta rápida depende de quién recibe
Elige getUpdates cuando la aplicación deba pedir Updates por long polling y pueda administrar offset, proceso y un único poller. Elige webhook cuando Telegram deba enviar POST a un HTTPS público y el equipo pueda operar disponibilidad, verificación y procesamiento seguro frente a repeticiones.
Telegram documenta ambos como métodos excluyentes. Ninguno es siempre más rápido o fiable.
| Pregunta | getUpdates | Webhook |
|---|---|---|
| Quién inicia | La aplicación consulta | Telegram envía POST HTTPS |
| Confirmación | Offset posterior al update_id | Respuesta HTTP y estado durable |
| Prueba del modo | URL vacía y poller observado | URL configurada en getWebhookInfo |
| Estado de corte | Offset y poller único | Endpoint, secreto y respuesta |
| Falso diagnóstico | Poller parado u offset errado | Endpoint sano, handler fallido |
La tabla compara custodia, no rendimiento. Volumen, latencia y coste siguen desconocidos.
Qué establecen los métodos oficiales
getUpdates devuelve Updates mediante long polling. Una llamada con offset mayor que un update_id confirma ese Update. Un offset negativo recupera desde el final y olvida elementos anteriores, por lo que el checkpoint es un activo de migración.
El timeout predeterminado es cero, polling corto, que Telegram reserva para pruebas. Eso no convierte el long polling en una técnica solo de desarrollo.
setWebhook registra una URL HTTPS. Telegram envía un Update JSON y repite peticiones no 2XY sin publicar un calendario fijo. secret_token llega en X-Telegram-Bot-Api-Secret-Token para verificar la configuración.
deleteWebhook elimina la integración. getWebhookInfo muestra URL, cola pendiente, IP, último error, conexiones y tipos permitidos. Una URL vacía indica uso de getUpdates.
La cola pendiente es una decisión empresarial
Telegram retiene Updates como máximo 24 horas. setWebhook y deleteWebhook ofrecen drop_pending_updates, que descarta la cola.
No debe ocultarse como valor por defecto. En un bot de pedidos, descartar puede perder acciones; en pruebas, reproducir eventos antiguos puede ser peor. El dueño decide.
- Estado redactado de
getWebhookInfo. - Conteo pendiente y
allowed_updates. - Último offset confirmado.
- Hora desde la que manda el nuevo receptor.
- Decisión de drenar, reproducir o descartar.
- Clave de idempotencia para una sola acción empresarial.
Con estos datos, llegar un día tarde puede permitir que otro proveedor defina el corte. Antes, responder rápido no completa el alcance. La reparación de duplicados cubre idempotencia, no prueba la necesidad de migrar.
Tres mensajes describen tres proyectos
«Webhook da 200, pero CRM pierde pedidos». Primero sigue el Update con el mapa de cuatro recibos; puede ser handler o CRM.
«El worker privado no expone HTTPS; cambiamos a long polling en mantenimiento». Sí parece migración, pero faltan cola, offset, poller único y rollback.
«getUpdates se detiene tras desplegar y vuelve al reiniciar». Puede ser supervisión, red o checkpoint dentro del modo actual.
No son clientes reales ni prueban un método superior; muestran cómo los sustantivos definen al propietario técnico.
Un corte con final observable
La migración tiene seis controles:
- Línea base: modo, tipos, cola y checkpoint.
- Pausa: impedir dos efectos empresariales durante el cambio.
- Cola: drenar, conservar o descartar con aprobación.
- Cambio: eliminar o fijar webhook y activar solo el receptor objetivo.
- Aceptación: enviar eventos propios y confirmar un resultado durable por tipo.
- Rollback: restaurar modo y checkpoint sin adivinar.
«El proceso está vivo» no basta. Debe haber un receptor, custodia intencional, eventos observados, efectos seguros y rollback.
Cuándo revisar inmediatamente el hilo
El hilo fuerte nombra entorno, métodos, propietario, plazo y restricción operativa sin publicar tokens. El débil repite «webhook malo» o «polling lento».
TOP Prospect conserva fragmentos autorizados, fuentes, horas, restricciones y desconocidos para revisión humana. No inspecciona el bot, no llama métodos, no verifica endpoints, no cambia infraestructura ni contacta al autor. La interfaz actual guarda nuevos objetivos, pero no genera candidatos automáticamente.
El artículo de timeout separa hosting de aplicación; Bot API frente a MTProto trata otra capa. Consulta precios.
Datos clave
- Webhook y
getUpdatesson excluyentes. - El offset confirma progreso; long polling no es polling corto de pruebas.
- Webhook necesita HTTPS y puede usar un encabezado secreto.
getWebhookInfoaporta evidencia de modo y cola.drop_pending_updatesdescarta Updates.- El método no prueba rendimiento, causa ni autoridad comercial.
Preguntas frecuentes
¿Pueden funcionar ambos métodos?
No, Telegram los define como excluyentes.
¿getUpdates es solo desarrollo?
No; la limitación oficial se refiere al polling corto.
¿Qué significa drop_pending_updates?
Descartar la cola, con aprobación del responsable.
¿Cuándo termina la migración?
Cuando hay un receptor, cola decidida, eventos durables sin duplicados y rollback registrado.
Revisión editorial completada el 26 de agosto de 2026 con la documentación oficial de Telegram.
Preguntas frecuentes
¿Puede un bot usar webhook y getUpdates a la vez?
No. Telegram los documenta como métodos mutuamente excluyentes.
¿getUpdates es solo para desarrollo?
No. Telegram limita el polling corto a pruebas; getUpdates también admite long polling.
¿Qué hace drop_pending_updates?
Descarta actualizaciones pendientes; debe ser una decisión explícita del responsable.
¿Qué debe demostrar la aceptación?
Un receptor activo, cola intencional, tipos requeridos entregados, procesamiento sin duplicados y rollback asignado.
Fuentes y lecturas adicionales
Cómo se descubre una Signal que merece atención
La metodología muestra cómo Top Prospect encuentra y organiza Signals que conviene revisar, conserva el contexto original de Telegram, elimina duplicados y ayuda a decidir qué mirar primero. Tú decides si hacer seguimiento y qué hacer después.
