Webhooks o polling: cómo debe recibir mensajes tu bot

Tres formas en que los eventos llegan a un bot

1. Long polling. Tu bot llama a un endpoint como getUpdates de Telegram con un timeout. El servidor mantiene la petición abierta hasta que hay una actualización o vence el timeout, y el bot vuelve a preguntar.
2. Webhooks. Registras una URL HTTPS pública. La plataforma envía un POST HTTP por cada evento.
3. Sockets persistentes. El bot abre un WebSocket (Gateway de Discord, Socket Mode de Slack) y recibe los eventos por ahí.

Comparación

Long polling: lo mejor para desarrollo

El polling solo necesita HTTPS saliente, así que funciona en una laptop detrás del router de tu casa. Eso lo hace ideal para desarrollo y para bots pequeños en una sola máquina.

Su modo de falla es la concurrencia. Telegram solo permite un consumidor: si un segundo proceso llama a getUpdates, o hay un webhook configurado, obtienes 409 Conflict. Ejecuta exactamente un proceso de polling y llama a deleteWebhook antes de empezar. Recuerda confirmar las actualizaciones pasando offset como el último update_id más uno, o las procesarás de nuevo.

Webhooks: lo mejor para producción

Con webhooks, la plataforma es la que espera. Tu código solo se ejecuta cuando hay trabajo, lo que hace a los webhooks baratos y naturales para serverless. También escalan horizontalmente: pon varias instancias detrás de un balanceador.

Los webhooks traen tres obligaciones:

• Verifica al remitente. Cualquiera puede hacer POST a una URL pública. Revisa el encabezado X-Telegram-Bot-Api-Secret-Token de Telegram, X-Slack-Signature de Slack, X-Hub-Signature-256 de Meta o la firma Ed25519 de Discord. Nuestro generador de firmas ayuda a depurarlo.
• Responde rápido. Las plataformas tienen timeouts y reintentan. Slack espera una respuesta en menos de 3 segundos y reintenta hasta tres veces; GitHub espera una respuesta en menos de 10 segundos. Confirma con 200 y pasa el trabajo lento a una cola.
• Sé idempotente. Los reintentos generan duplicados. Guarda el ID del evento o de la actualización y omite los que ya procesaste.

Los webhooks de Telegram deben usar HTTPS en el puerto 443, 80, 88 u 8443.

Sockets: cuando la plataforma los exige

Algunas funciones solo existen en un socket. Un bot de Discord que reacciona a mensajes normales, a la llegada de miembros o a la presencia necesita el Gateway. Socket Mode de Slack es práctico para apps internas detrás de un firewall, porque no necesita URL pública.

El costo es un proceso siempre encendido y lógica de reconexión. Usa una biblioteca mantenida (discord.js, discord.py, Bolt) en lugar de implementar el protocolo tú mismo.

Una regla práctica

• Desarrollo local: polling o Socket Mode.
• Producción, trabajo basado en peticiones: webhooks.
• Producción, necesitas flujos de mensajes o presencia: un socket, en un proceso supervisado y siempre encendido.

Puedes combinarlos: un bot de Discord puede recibir comandos slash por un endpoint de interacciones HTTP sin usar el Gateway en absoluto, lo que facilita mucho el hosting.

Probar webhooks sin desplegar

Usa un túnel (Cloudflare Tunnel o ngrok) para exponer tu servidor local, o reproduce payloads guardados con nuestro simulador de webhooks. Reproducir un payload real es más rápido que esperar a la plataforma y más fácil de repetir.

Fuentes

• getUpdates y setWebhook de Telegram: core.telegram.org/bots/api#getting-updates
• Reintentos de la Events API de Slack: api.slack.com/apis/events-api#retries
• Buenas prácticas de webhooks de GitHub: docs.github.com/webhooks/using-webhooks/best-practices-for-using-webhooks
• Gateway de Discord: discord.com/developers/docs/events/gateway