¿Cómo crear un bot en Telegram y automatizar sus respuestas?

Qué es un bot de Telegram y qué se puede automatizar realmente

Aprender a crear un bot en Telegram consiste, en la práctica, en conectar una cuenta especial de la aplicación con un programa que responde en tu nombre. Un bot no es un usuario humano ni un canal: es una cuenta gestionada por software que se comunica con los servidores de Telegram a través de la Bot API, una interfaz HTTP documentada por la propia plataforma. Todo lo que el bot hace —enviar un mensaje, mostrar un menú de comandos, reenviar un archivo, registrar una reserva o confirmar una suscripción— ocurre porque tu código se lo pidió a esa API y Telegram se limitó a ejecutar la orden.

Esa separación de responsabilidades es la idea central del artículo y también la que genera más expectativas equivocadas. Telegram aporta la infraestructura de mensajería, la identidad del bot y la entrega de eventos; tú aportas la lógica, el servidor donde vive esa lógica y la responsabilidad sobre lo que el bot publica. Si esperabas que BotFather, el bot oficial que crea y administra otros bots dentro de la aplicación, generase por sí solo respuestas inteligentes, conviene corregir esa idea ahora: BotFather crea la identidad del bot y ajusta sus metadatos, pero no aloja ni ejecuta tu código.

Para calibrar con precisión dónde queda ese límite, ayuda distinguir el bot de las funciones que se le parecen. Un canal es un mecanismo de difusión: alguien publica y los suscriptores leen, sin margen de réplica. Un bot, en cambio, es un mecanismo de interacción: recibe eventos dirigidos a él —un mensaje, una pulsación de botón, la entrada de un nuevo miembro— y puede reaccionar a cada uno de forma distinta. Un grupo, por su parte, es una conversación entre personas donde un bot puede participar como un miembro más, pero con reglas de visibilidad propias que veremos unas secciones más adelante.

Requisitos previos y expectativas realistas

El primer requisito es una cuenta de Telegram activa con un número de teléfono verificado. No necesitas cuenta premium, ni tarjeta de crédito, ni aprobaciones del equipo de Telegram para registrar un bot. Tampoco necesitas ser desarrollador si tu plan se limita a crear la identidad del bot y usar los comandos de configuración; sí lo necesitarás en cuanto quieras lógica propia, como consultar una base de datos, validar un pago o publicar en horarios concretos.

La segunda expectativa que conviene ajustar es la del alcance. Un bot no puede iniciar una conversación con una persona que nunca le haya escrito. El usuario debe abrir el chat del bot y pulsar el botón de inicio, o enviar un comando, para que la conversación exista técnicamente. Esto es una decisión de diseño de la plataforma orientada a evitar el spam, y determina qué casos de uso tienen sentido: un bot sirve muy bien para atención entrante, avisos a quien ya se suscribió o gestión dentro de un grupo, pero no reemplaza una campaña de mensajes en frío.

De ahí se desprende una tercera consideración, más de infraestructura que de producto. Si vas a trabajar sin código, te bastará con la aplicación de Telegram. Si vas a trabajar con código, necesitarás además un entorno donde ejecutarlo: tu propio ordenador para las pruebas y, más adelante, un servidor o servicio de alojamiento para que el bot siga vivo cuando apagues el equipo. Ese salto, del prototipo local al servicio en producción, es donde aparecen la mayoría de los problemas que se describen más adelante, así que conviene asumirlo como una etapa propia y no como un detalle final.

Paso 1: registrar el bot con BotFather en cada plataforma

El registro es idéntico en concepto en todas las plataformas, pero la ruta hasta el chat cambia ligeramente según el cliente que uses. En cualquier caso, el primer paso es abrir la conversación con @BotFather, que aparece con la insignia de verificación oficial. Evita cualquier variante con nombres parecidos: el identificador correcto es exactamente ese, y confundirlo con una imitación es una de las vías más habituales de robo de tokens.

Ruta en Android y en iOS

Toca la barra de búsqueda superior, escribe BotFather y abre el resultado verificado. En la parte inferior del chat verás el botón de inicio; en Android aparece como un botón flotante con la etiqueta de comenzar y en iOS como un botón en la parte baja de la pantalla. Púlsalo para habilitar la conversación y después escribe el comando /newbot en el campo de texto y envíalo.

BotFather responderá con dos preguntas consecutivas: primero el nombre visible del bot, que puede contener espacios y no tiene que ser único, y después el nombre de usuario, que sí debe ser único en toda la plataforma y debe terminar obligatoriamente en la terminación bot. Si el nombre elegido ya está ocupado, el asistente lo rechazará y te pedirá otro; es la causa más común de fricción en este paso. Reserva unos minutos para probar variantes antes de frustrarte, porque la disponibilidad de nombres cortos es limitada y el proceso rara vez sale a la primera.

Ruta en Telegram Desktop y Telegram Web

En el cliente de escritorio, usa el campo de búsqueda de la esquina superior izquierda, escribe BotFather y abre el chat verificado. La diferencia práctica es que no hay botón de inicio flotante: basta con escribir directamente /newbot y pulsar Intro, porque el cliente de escritorio ya envía el comando. En Telegram Web el comportamiento es equivalente, con la salvedad de que el portapapeles y la gestión de sesiones dependen del navegador, algo relevante cuando llegue el momento de copiar el token.

Una nota de plataforma que suele pasar desapercibida: en macOS, la aplicación de escritorio nativa y la versión web comparten cuenta pero no siempre comparten el estado de la sesión de la misma forma. Si trabajas en varios dispositivos a la vez, el mensaje con el token aparecerá en todos, lo cual es cómodo para copiarlo pero también significa que cualquier dispositivo con sesión iniciada puede verlo. Tenlo presente al elegir desde dónde generas el bot: la comodidad de tenerlo en todas partes es también la superficie que hay que proteger.

Qué guardar del mensaje de BotFather y por qué es sensible

Al finalizar el registro, BotFather devuelve un mensaje con el enlace al bot y una cadena denominada token de acceso, con una estructura del tipo un identificador numérico seguido de dos puntos y una clave alfanumérica. Ese token es la única credencial del bot: quien lo tenga puede actuar como él, leer las actualizaciones pendientes y enviar mensajes en su nombre. No es una contraseña recuperable, es una llave, y como tal conviene tratarla desde el primer minuto.

Guárdalo en un gestor de contraseñas o en una variable de entorno, nunca en una captura de pantalla compartida ni en un repositorio público. Si sospechas que se ha filtrado, el propio BotFather ofrece el comando /revoke para invalidar el token actual y emitir uno nuevo; el bot seguirá existiendo con el mismo nombre de usuario, pero el acceso anterior dejará de funcionar. También puedes consultar el token existente con /token y administrar todos tus bots con /mybots, que abre un menú con opciones de edición y borrado.

Paso 2: decidir entre polling y webhooks antes de escribir código

Cuando el bot ya existe, llega la decisión técnica más determinante del proyecto: cómo va a recibir los mensajes que le envían. La Bot API ofrece dos mecanismos y son mutuamente excluyentes en la práctica, porque si configuras un webhook activo, las llamadas a la consulta de actualizaciones dejan de devolver mensajes nuevos hasta que lo elimines. Elegir bien aquí ahorra reescrituras más adelante.

Consulta periódica de actualizaciones

El primer mecanismo, conocido como long polling, consiste en que tu programa pregunta repetidamente a Telegram si hay novedades pendientes mediante el método getUpdates de la Bot API. Es el enfoque más sencillo de arrancar: funciona desde cualquier ordenador con conexión a internet, no necesita certificado ni dominio, y basta con un bucle que reciba la lista de actualizaciones, procese cada una y confirme el desplazamiento del puntero de lectura para no repetir mensajes ya tratados.

Su punto débil es la dependencia de un proceso siempre encendido y bien comportado. Si el programa se detiene, los mensajes se acumulan en el lado de Telegram y se entregan cuando vuelve a consultar, lo cual es cómodo para pruebas pero puede generar ráfagas difíciles de gestionar en producción. Además, si ejecutas dos instancias del mismo bot con el mismo token, ambas competirán por las mismas actualizaciones y verás respuestas duplicadas o perdidas.

Webhook: Telegram empuja hacia tu servidor

El segundo mecanismo invierte la dirección. Con el método setWebhook le indicas a Telegram una URL HTTPS pública; desde ese momento, cada evento se envía como una petición HTTP POST a esa dirección, con el contenido de la actualización en formato JSON. Tu servidor solo tiene que escuchar, validar y responder con un código de éxito en un tiempo razonable. La ventaja es la latencia baja y la ausencia de bucles; el coste es que necesitas un certificado válido, un dominio accesible y un servicio estable.

Telegram admite únicamente endpoints sobre HTTPS con certificados emitidos por entidades reconocidas, aunque existe la posibilidad de subir un certificado propio autofirmado como parámetro adicional. Si el certificado caduca o la URL deja de responder, Telegram registrará el error y reintentará con una política de espera creciente; puedes inspeccionar ese estado en cualquier momento con el método getWebhookInfo, que informa de la URL configurada, de si hay actualizaciones pendientes y del último mensaje de error registrado.

Criterio	Long polling	Webhook
Infraestructura necesaria	Un proceso en ejecución	Servidor con HTTPS público
Facilidad de inicio	Alta, sin dominio ni certificado	Media, requiere configuración previa
Latencia percibida	Depende del intervalo de consulta	Entrega inmediata del evento
Uso recomendado	Prototipos, bots internos, pruebas	Producción con tráfico continuo

La regla práctica que mejor funciona: empieza con long polling para validar la lógica del bot y migra a webhook cuando el bot tenga usuarios reales y necesites disponibilidad. No es una decisión irreversible. Cambiar de uno a otro no afecta a la identidad del bot ni a su historial de conversaciones, solo al modo en que los eventos llegan a tu programa, así que puedes posponerla sin miedo mientras el prototipo siga dándote información.

Paso 3: configurar comandos y metadatos sin escribir código

Antes de programar vale la pena dejar presentable el bot, porque la primera impresión de un usuario ocurre en la pantalla de perfil. BotFather permite ajustar el nombre, la descripción corta, el texto de presentación, la imagen de perfil y la lista de comandos sugeridos. Todo esto se hace conversando con BotFather y eligiendo el bot correspondiente en cada comando, sin tocar una sola línea de código.

Comandos útiles de administración

• /setname cambia el nombre visible del bot.
• /setdescription define el texto que se muestra antes de iniciar la conversación.
• /setabouttext ajusta la descripción que aparece en el perfil del bot.
• /setuserpic permite subir una imagen de perfil.
• /setcommands publica la lista de comandos que el cliente mostrará en el menú al escribir una barra.
• /setjoingroups habilita o deshabilita que el bot pueda ser añadido a grupos.
• /setprivacy controla el modo de privacidad dentro de los grupos.
• /setinline activa o desactiva el modo en línea.

El comando de privacidad merece un párrafo aparte porque explica por qué muchos bots parecen sordos en los grupos. Con el modo de privacidad activado, que es el comportamiento por defecto, el bot solo recibe los mensajes que son comandos dirigidos a él, las respuestas a sus propios mensajes y las menciones explícitas. No ve el resto de la conversación. Si necesitas que lea todo lo que se escribe en el grupo, deberás desactivar ese modo y volver a añadir el bot al grupo para que el cambio surta efecto; hacerlo implica asumir responsabilidad sobre datos de terceros, así que aplícalo solo cuando el caso de uso lo justifique.

El límite real de la configuración sin código

Conviene decirlo con claridad: BotFather no permite definir respuestas automáticas arbitrarias. Puedes declarar que existe un comando llamado /horario y describir qué hace, pero el bot no enviará nada hasta que tu programa reciba ese comando y decida qué contestar. La lista de comandos es un menú, no una máquina de reglas. Cualquier expectativa de crear «respuestas automáticas» sin código se topa con esta pared y es la razón por la que el siguiente paso del artículo implica programar.

Paso 4: automatizar respuestas con un ejemplo mínimo reproducible

Llegamos al núcleo de la automatización. El objetivo de este ejemplo es tener un bot que responda a dos comandos y a cualquier texto libre, usando long polling para no depender de infraestructura externa. Se elige Python por su legibilidad y porque la biblioteca estándar de peticiones HTTP es suficiente; no hace falta ningún marco de trabajo adicional para esta primera prueba.

Estructura mínima del proyecto

Crea una carpeta con dos archivos: uno para el código y otro para las dependencias, si decides usar un entorno virtual. El token nunca debe escribirse dentro del código; se toma de una variable de entorno para que puedas compartir el proyecto sin filtrar credenciales. La estructura es deliberadamente plana porque el propósito es entender el ciclo completo antes de añadir complejidad.

TELEGRAM_TOKEN=tu_token_aqui

Ejemplo de long polling

El programa consulta periódicamente las actualizaciones, extrae el texto y el identificador del chat, y responde según el contenido. El parámetro de desplazamiento evita procesar dos veces el mismo mensaje, y un pequeño retardo entre consultas vacías reduce el consumo innecesario de red.

import os, time, requests

TOKEN = os.environ['TELEGRAM_TOKEN']
BASE = f'https://api.telegram.org/bot{TOKEN}'

def enviar(chat_id, texto):
    requests.post(f'{BASE}/sendMessage', json={'chat_id': chat_id, 'text': texto})

def principal():
    offset = None
    while True:
        params = {'timeout': 30}
        if offset:
            params['offset'] = offset
        r = requests.get(f'{BASE}/getUpdates', params=params, timeout=40)
        datos = r.json()
        for act in datos.get('result', []):
            offset = act['update_id'] + 1
            mensaje = act.get('message')
            if not mensaje:
                continue
            chat_id = mensaje['chat']['id']
            texto = (mensaje.get('text') or '').strip()
            if texto == '/start':
                enviar(chat_id, 'Bot activo. Escribe /ayuda para ver las opciones.')
            elif texto == '/ayuda':
                enviar(chat_id, 'Comandos disponibles: /start, /ayuda, /estado')
            elif texto == '/estado':
                enviar(chat_id, 'El servicio esta operativo.')
            else:
                enviar(chat_id, 'He recibido tu mensaje y lo he registrado.')
        time.sleep(1)

if __name__ == '__main__':
    principal()

Observa tres decisiones de diseño que conviene replicar en proyectos mayores. La primera es que el token se lee del entorno. La segunda es que cada actualización se reconoce con su identificador antes de procesarla. La tercera es que la respuesta se delega en una función única, de modo que cambiar el canal de salida más adelante no obligue a reescribir toda la lógica. Ninguna de las tres cuesta esfuerzo hoy, y las tres ahorran trabajo cuando el bot crezca.

Para probarlo, envía /start a tu bot desde cualquier cliente y comprueba que responde. Si el bot no contesta pero el programa no muestra errores, lo más probable es que el token esté mal copiado, que exista otro proceso consumiendo las actualizaciones con el mismo token o que haya un webhook configurado previamente que esté bloqueando la entrega. Eliminar el webhook con deleteWebhook resuelve el último caso, y es la primera comprobación que deberías hacer antes de tocar el código.

Paso 5: publicar el bot con webhook en un servidor

Cuando el prototipo funciona, el salto a producción consiste en alojar el código en un servicio que permanezca encendido y exponerlo mediante una URL HTTPS. Existen muchas rutas válidas: un servidor propio con un proxy inverso, una plataforma de funciones sin servidor o un contenedor gestionado. Lo importante no es la marca de la herramienta, sino cumplir tres condiciones: certificado válido, endpoint que responda rápido y verificación del origen de las peticiones.

Registrar el webhook y protegerlo

El registro se hace con una sola llamada al método setWebhook indicando la URL. Si quieres una capa adicional de seguridad, puedes acompañarla de un parámetro de secreto compartido; Telegram lo enviará de vuelta en cada petición dentro de una cabecera específica, y tu servidor puede rechazar cualquier solicitud que no lo incluya. Es una medida barata que evita que terceros envíen eventos falsos a tu endpoint si descubren la dirección.

curl -s 'https://api.telegram.org/botTU_TOKEN/setWebhook' \
  -d 'url=https://tu-dominio.example/webhook' \
  -d 'secret_token=una_cadena_larga_aleatoria'

Tras registrarlo, comprueba el estado con getWebhookInfo. Ese método devuelve la URL configurada, el número de actualizaciones en cola y, si algo ha fallado, la fecha y el mensaje del último error. Es la primera consulta que deberías hacer ante cualquier incidencia de entrega, porque te ahorra revisar el código cuando el problema está en la red.

Errores frecuentes al pasar a producción

El primero es responder con lentitud. Tu servidor debe acusar recibo del evento en pocos segundos y, si el procesamiento es pesado, encolarlo y responder de inmediato. El segundo es no controlar los reintentos: si tu endpoint falla repetidamente, Telegram acumulará actualizaciones pendientes y la cola crecerá. El tercero es olvidar la limpieza: si abandonas el proyecto, conviene revocar el token y borrar el bot con /deletebot para no dejar una identidad activa y sin dueño.

Tres escenarios concretos para decidir con criterio

La teoría se entiende mejor con casos acotados, porque cada uno deja ver una parte distinta del diseño. Imagina primero un canal de avisos con una audiencia de decenas de miles de suscriptores que recibe varias publicaciones al día. Aquí el bot actúa como publicador: se le añade al canal como administrador y ejecuta el envío mediante la API desde tu sistema de origen. La automatización útil no está en responder a nadie, sino en garantizar la entrega ordenada y en gestionar los límites de frecuencia que Telegram aplica a los envíos masivos.

El segundo escenario es la atención entrante en un comercio pequeño. El bot recibe el primer mensaje, presenta un menú de opciones mediante la lista de comandos y deriva a una persona cuando el usuario escribe una palabra clave. Aquí el valor está en filtrar y clasificar, no en responder todo automáticamente. Un bot que promete resolver cualquier consulta y falla en la tercera pregunta produce peor impresión que uno que reconoce sus límites y transfiere rápido.

El tercer escenario es un grupo grande con normas de convivencia. El bot puede dar la bienvenida a los nuevos miembros, recordar las reglas y registrar incidencias, pero solo verá los mensajes si se desactiva el modo de privacidad. Antes de hacerlo, conviene preguntarse si de verdad hace falta leer toda la conversación o basta con reaccionar a comandos y menciones, porque la opción más restrictiva es casi siempre la más defendible y la que menos obligaciones añade.

Límites, riesgos y cuándo no conviene usar un bot

Telegram impone límites de frecuencia a los envíos para proteger la infraestructura. No conviene memorizar cifras porque cambian y suelen actualizarse en la documentación oficial; lo relevante es asumir que existen y diseñar con ellos en mente. En la práctica, esto se traduce en enviar por lotes controlados, espaciar los avisos y evitar bucles que disparen mensajes ante un error.

Hay situaciones en las que un bot es la herramienta equivocada. Si necesitas conversaciones con matices humanos, si el volumen de interacción es muy bajo y esporádico, o si el requisito principal es confidencialidad extrema sobre el contenido de los mensajes, probablemente un canal o un grupo moderado por personas funcione mejor. También conviene descartar el bot cuando la organización no puede mantener el servicio encendido ni asumir el coste de un servidor, porque un bot apagado genera más frustración que la ausencia de bot.

Desde el punto de vista del cumplimiento, el bot es un tratamiento de datos más. Si almacenas identificadores de chat, nombres o contenidos de mensajes, aplica el principio de mínimo privilegio: guarda solo lo imprescindible, define un periodo de retención y documenta para qué se usa cada dato. Desactivar el modo de privacidad en un grupo implica acceder a conversaciones de terceros, y esa decisión debería estar justificada y comunicada, no ser un ajuste tomado por comodidad.

Solución de problemas: síntoma, causa, verificación y arreglo

El bot no responde. La causa más probable es un problema de credenciales o de método de recepción. Verifica primero que el token sea el vigente consultándolo con /token en BotFather, después comprueba con getWebhookInfo si hay un webhook activo que esté desviando los eventos, y finalmente revisa que no haya dos procesos compitiendo por las mismas actualizaciones. La resolución habitual es revocar el token, eliminar el webhook y reiniciar un único proceso.

El bot responde dos veces al mismo mensaje. Suele deberse a instancias duplicadas del programa en ejecución, algo frecuente cuando se prueba en local mientras el servicio en producción sigue activo. Verifícalo revisando los procesos del servidor y los registros de arranque. La solución es garantizar una única instancia o pasar a webhook, que elimina estructuralmente este problema porque no hay dos programas preguntando a la vez.

El bot funciona en un grupo pero no en otro. Comprueba el modo de privacidad y si el bot fue añadido antes o después de cambiar esa configuración; el cambio de privacidad requiere volver a añadir el bot al grupo para aplicarse. Verifica también que el bot tenga permiso para leer mensajes o para publicar, según lo que necesites.

Las respuestas llegan con retraso. Si usas long polling, el intervalo de consulta y el tiempo de espera configurado explican la mayor parte del retardo. Si usas webhook, revisa la latencia de tu servidor y si estás encolando eventos por detrás de un procesamiento lento. En ambos casos, medir antes de optimizar evita cambiar cosas que no eran el cuello de botella.

Checklist de mejores prácticas y mínimo privilegio

Antes de dar por bueno un bot, recorre esta lista. No es un formulario que rellenar, sino un conjunto de decisiones que reducen el riesgo de incidentes y hacen el proyecto mantenible cuando lo retomas meses después.

• El token vive en una variable de entorno o gestor de secretos, nunca en el código ni en el historial de conversaciones.
• Existe una única instancia en ejecución por cada token.
• El modo de privacidad permanece activo salvo justificación explícita y documentada.
• El endpoint del webhook valida el secreto compartido y responde con rapidez.
• Los registros no almacenan contenido sensible de los mensajes más tiempo del necesario.
• Los comandos anunciados en BotFather están implementados en el código.
• Hay un plan claro de retirada: revocar el token y eliminar el bot si el proyecto termina.

Ninguno de estos puntos exige herramientas especiales ni conocimientos avanzados; exigen constancia. La diferencia entre un bot que funciona meses y otro que se degrada casi siempre está en revisar esta lista cada vez que se introduce un cambio, y no solo el día en que se creó el proyecto.

Métodos de verificación y observación empírica

La forma más fiable de comprobar que un bot se comporta como esperas es ejecutar pruebas controladas y anotar el resultado. Un procedimiento reproducible sencillo consiste en lo siguiente: envía cada comando anunciado desde una cuenta distinta a la del desarrollador, cronometra de forma aproximada cuánto tarda la respuesta y registra si el texto devuelto coincide con lo esperado. Repite la secuencia justo después de reiniciar el servicio para detectar estados que solo existen en memoria y desaparecen al apagar el proceso.

Como observación empírica —es decir, como tendencia cualitativa observada y no como cifra garantizada—, el long polling suele percibirse algo más lento que el webhook cuando el intervalo de consulta no está ajustado, mientras que el webhook tiende a degradarse con más facilidad si el servidor tiene problemas de certificado o de disponibilidad. Verifica tu propia situación midiendo, no asumiendo, porque el resultado depende mucho del alojamiento elegido.

Otra verificación útil es revisar el estado de la entrega después de un fallo simulado. Detén el servicio unos minutos, envíale mensajes y vuelve a arrancarlo; con long polling deberías recibir las actualizaciones acumuladas, mientras que con webhook conviene consultar getWebhookInfo para ver si la cola de pendientes creció y si se registró algún error. Este ejercicio revela si tu configuración tolera interrupciones y cuánto tarda en recuperarse, dos datos que ningún documento te puede dar por ti.

Diferencias de plataforma y notas sobre versiones

La interfaz de Telegram evoluciona con frecuencia, así que conviene hablar de comportamiento general en lugar de numerar versiones. En la última versión al momento de escribir, los clientes de Android, iOS, escritorio y web comparten la práctica totalidad de las funciones descritas aquí, con diferencias que son de forma y no de fondo: el botón de inicio aparece como elemento flotante en los móviles y como acción implícita al escribir en el escritorio, y la copia del token es más cómoda con teclado físico que con pantalla táctil.

Si algo de lo que describes aquí no coincide con lo que ves, el primer paso es comprobar la versión instalada desde los ajustes de la aplicación y actualizarla desde la tienda oficial correspondiente. Los cambios en la Bot API se anuncian y documentan de forma centralizada, y suelen incorporarse a los clientes antes que a las bibliotecas de terceros, por lo que el desfase más habitual no está en la app sino en las dependencias de tu proyecto.

Tendencias futuras y expectativas de versión

Sin entrar en anuncios concretos, la tendencia razonable es que la plataforma siga añadiendo capacidades del lado del cliente antes de que las bibliotecas de terceros las absorban. Por eso conviene diseñar el bot de forma que la lógica de negocio no dependa de un detalle de interfaz: si mañana cambia la forma de mostrar un menú o de registrar un comando, tu programa debería seguir funcionando sin más ajuste que una actualización de dependencias. Mantener el código separado de la configuración del bot es la mejor preparación para cualquier cambio de versión.

Preguntas frecuentes

¿Se puede crear un bot en Telegram sin saber programar?

Sí para la parte de registro y configuración: BotFather permite crear el bot, definir su nombre, su descripción, su imagen y la lista de comandos sin escribir código. Sin embargo, las respuestas automáticas dependen siempre de un programa externo que reciba los mensajes y decida qué contestar, por lo que si necesitas lógica propia tendrás que programarla o contratar a alguien que lo haga.

¿Cuál es la diferencia entre long polling y webhook?

Con long polling tu programa pregunta repetidamente a Telegram si hay mensajes nuevos mediante getUpdates. Con webhook, tú registras una URL HTTPS con setWebhook y Telegram envía cada evento a esa dirección. El primero es más fácil de arrancar y no necesita dominio; el segundo ofrece menor latencia y mejor comportamiento en producción, a cambio de requerir certificado y un servidor disponible.

¿Por qué mi bot no recibe los mensajes de un grupo?

Lo más probable es que el modo de privacidad esté activo, que es el comportamiento por defecto. En ese estado el bot solo ve los comandos dirigidos a él, las respuestas a sus mensajes y las menciones explícitas. Si necesitas que lea toda la conversación, cambia el modo con el comando correspondiente en BotFather y vuelve a añadir el bot al grupo, porque el ajuste no se aplica a membresías ya existentes.

¿Qué hago si el token del bot se filtra?

Usa el comando de revocación en BotFather para invalidar el token actual y generar uno nuevo. El bot conserva su nombre de usuario y sus conversaciones, pero cualquier programa que estuviera usando el token antiguo dejará de funcionar y deberás actualizar el valor en tu servidor. Revisa además dónde se expuso para corregir la causa.

¿Puede un bot escribir a un usuario que nunca le ha hablado?

No. El usuario debe iniciar la conversación, normalmente pulsando el botón de inicio o enviando un comando, antes de que el bot pueda escribirle. Esta restricción de la plataforma impide usar bots como herramienta de mensajería en frío y condiciona los casos de uso válidos hacia la atención entrante y los avisos a suscriptores existentes.

Conclusión y siguientes pasos

Crear un bot en Telegram y automatizar sus respuestas es un proceso por etapas bien delimitadas: registrar la identidad con BotFather, decidir cómo recibirás los eventos, configurar los metadatos visibles, implementar la lógica y, solo cuando haga falta, moverla a un servidor con webhook. Cada etapa se puede probar por separado, y ese es el mejor consejo práctico del artículo: no mezcles el registro con la programación ni la programación con el despliegue, porque cuando algo falla necesitarás saber en qué capa está el problema.

Si acabas de empezar, el siguiente paso razonable es registrar el bot, obtener el token y ejecutar el ejemplo de long polling con dos o tres comandos. Cuando esa base responda de forma estable, añade una única función de valor real —consultar un dato, registrar una solicitud, enviar un aviso programado— y observa cómo se comporta durante unos días. Si el uso crece y necesitas disponibilidad continua, entonces plantéate el webhook y el alojamiento; hacerlo antes solo añade complejidad sin beneficio.

Y si el proyecto se detiene, ciérralo bien: revoca el token, elimina el bot si no lo vas a reutilizar y borra los datos personales que hayas almacenado. Un bot es una identidad pública y una responsabilidad operativa, no un experimento que se pueda abandonar sin consecuencias.