Como enviar notificaciones de Telegram desde tu servidor

Tienes un servidor corriendo en algun lugar — quiza una API de Node.js en un VPS, un script de Python en un cron job, o un servicio de Go en un contenedor Docker. Algo pasa (un deploy termina, llega un pago, un job en segundo plano falla) y quieres saberlo. Ahora mismo. En tu telefono.

Telegram es perfecto para esto. Es rapido, funciona en todos los dispositivos, las notificaciones realmente aparecen (a diferencia del email), y probablemente ya lo tienes abierto. El problema es que configurar la API de Telegram Bot directamente es complicado: necesitas crear un bot con BotFather, gestionar tokens, averiguar los chat IDs, manejar el webhook o polling, y escribir las llamadas HTTP tu mismo. Para que? Para enviar un mensaje de texto.

Hay una forma mas simple. Dejame mostrarte como lo hago yo.

La forma dificil: API de Telegram Bot directamente

Si lo has intentado antes, ya conoces el proceso. Vas a BotFather, creas un bot, obtienes un token, y luego averiguas que chat_id tiene tu usuario o grupo. Terminas escribiendo algo como esto:

# You need to know your chat_id beforehand
# And manage the bot token yourself
# And handle errors, retries, rate limits...

curl -s -X POST \
  https://api.telegram.org/bot<YOUR_BOT_TOKEN>/sendMessage \
  -d chat_id=<CHAT_ID> \
  -d text="Deploy finished"

Funciona. Pero ahora necesitas gestionar ese token de bot de forma segura, llevar un registro de los chat IDs de cada persona o grupo que quieras notificar, manejar los limites de tasa de Telegram (30 mensajes por segundo a diferentes chats, 1 por segundo al mismo chat), y lidiar con fallos de entrega. Si quieres enviar tambien a Discord o Slack despues, eso es una integracion completamente separada.

Para un script rapido, quiza este bien. Pero si estas construyendo algo real — un SaaS, una configuracion de monitoreo, un sistema de notificaciones para un equipo — esto se vuelve desordenado rapido.

La forma facil: Una llamada a la API

Con NotificationsBot, te saltas todo eso. Sin tokens de bot, sin chat IDs, sin servidores de webhook. Haces un HTTP POST a una API REST, y el mensaje aparece en Telegram. Asi se ve:

curl -s -X POST https://api.notificationsbot.com/event \
  -H "Authorization: Bearer $NOTIFICATIONSBOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "server-alerts",
    "title": "Deploy finished",
    "message": "v2.4.1 deployed to production successfully."
  }'

Eso es todo. La notificacion llega a tu Telegram en menos de 2 segundos. Sin codigo especifico de Telegram, sin gestion de bots, sin chat IDs que buscar. Y si manana quieres la misma notificacion en Discord o Slack, solo agregas un suscriptor al canal — sin cambios de codigo.

Configuracion (5 minutos)

Antes de poder enviar esa primera peticion, necesitas tres cosas: una cuenta, un canal y un suscriptor. Aqui esta la version rapida:

• Registrate en app.notificationsbot.com — plan gratuito, sin tarjeta de credito
• Crea un canal (por ejemplo, server-alerts) — aqui es donde enviaras los eventos
• Agregate como suscriptor — haz clic en el enlace de onboarding, abrelo en Telegram, presiona Start
• Asigna el suscriptor al canal — ahora ese canal entrega a tu Telegram
• Crea una API key en Settings — esto autentica tu servidor

Esa es la configuracion unica. A partir de aqui, son solo llamadas a la API desde tu codigo.

Ejemplos reales de servidores reales

Asi es como realmente uso esto en produccion. Estos no son hipoteticos — son patrones que he puesto en proyectos reales.

Notificaciones de despliegue

Al final de tu pipeline de CI/CD, agrega un paso. Tu equipo sabe en el momento en que un deploy sale, sin revisar GitHub o esperar a que alguien diga "acabo de hacer deploy."

# Add this as the last step in your deploy script
curl -s -X POST https://api.notificationsbot.com/event \
  -H "Authorization: Bearer $NOTIFICATIONSBOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"channel\": \"deployments\",
    \"title\": \"Deployed to production\",
    \"message\": \"$APP_NAME v$VERSION deployed by $GITHUB_ACTOR\"
  }"

Fallos de cron jobs

Los cron jobs fallan en silencio. Esa es su naturaleza. El script de backup que ha estado roto por dos semanas? Nadie se dio cuenta porque el output va a /dev/null. Arregla eso con tres lineas:

#!/bin/bash
# backup.sh

pg_dump mydb > /backups/mydb_$(date +%F).sql

if [ $? -ne 0 ]; then
  curl -s -X POST https://api.notificationsbot.com/event \
    -H "Authorization: Bearer $NOTIFICATIONSBOT_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "channel": "server-alerts",
      "title": "Backup failed",
      "message": "Database backup for mydb failed. Check the server."
    }'
fi

Monitoreo de errores en tu app

No necesitas una plataforma completa de observabilidad para saber cuando las cosas se rompen. A veces un mensaje de Telegram es todo lo que necesitas. Asi es como conectarlo en los lenguajes que probablemente estes usando:

# notify.py
import os
import requests

API_KEY = os.environ["NOTIFICATIONSBOT_API_KEY"]

def notify(title: str, message: str, channel: str = "server-alerts"):
    requests.post(
        "https://api.notificationsbot.com/event",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"channel": channel, "title": title, "message": message},
        timeout=5,
    )

# In your code:
try:
    process_payment(order)
except Exception as e:
    notify("Payment failed", f"Order #{order.id}: {str(e)}")

// notify.js
const API_KEY = process.env.NOTIFICATIONSBOT_API_KEY;

async function notify(title, message, channel = "server-alerts") {
  await fetch("https://api.notificationsbot.com/event", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ channel, title, message }),
  });
}

// In your Express error handler:
app.use((err, req, res, next) => {
  notify("Server error", `${req.method} ${req.path}: ${err.message}`);
  res.status(500).json({ error: "Internal server error" });
});

// notify.go
package main

import (
    "bytes"
    "encoding/json"
    "net/http"
    "os"
)

func notify(title, message string) {
    body, _ := json.Marshal(map[string]string{
        "channel": "server-alerts",
        "title":   title,
        "message": message,
    })

    req, _ := http.NewRequest("POST",
        "https://api.notificationsbot.com/event",
        bytes.NewBuffer(body))
    req.Header.Set("Authorization", "Bearer "+os.Getenv("NOTIFICATIONSBOT_API_KEY"))
    req.Header.Set("Content-Type", "application/json")

    http.DefaultClient.Do(req)
}

Por que no simplemente usar la API de Telegram Bot?

Absolutamente puedes hacerlo. Si tienes un servidor, una persona que notificar, y no te importa gestionar tokens de bot y chat IDs, el enfoque directo funciona. Pero esto es lo que obtienes con NotificationsBot que no obtienes con Telegram directo:

• Sin gestion de bots — no creas, alojas ni mantienes un bot de Telegram
• Gestion de suscriptores — agrega/elimina personas desde el panel, sin cambios de codigo
• Multi-canal — la misma API envia a Telegram, Discord, Slack y Email
• Logs de eventos — cada notificacion se registra en tu panel con marcas de tiempo
• Equipos — invita a companeros, gestiona quien recibe que, sin compartir tokens de bot
• Monitoreo de URLs — health checks integrados que alertan automaticamente, sin codigo necesario

Si estas construyendo algo para ti mismo y un script rapido es suficiente, ve directo. Si estas construyendo algo para un equipo o un producto, usa una API que maneje las partes dificiles.

Yendo mas alla

Una vez que lo basico esta funcionando, aqui hay algunas ideas para hacer tu configuracion de notificaciones realmente util:

• Crea canales separados para diferentes preocupaciones: deployments, errors, payments, monitoring
• Usa grupos para enrutar un evento a multiples canales a la vez (por ejemplo, "critical" va tanto a Telegram como a Slack)
• Agrega health checks de URLs desde el panel — sin codigo, solo pega la URL y elige quien recibe la alerta
• Incluye contexto en tus mensajes — stack traces, IDs de ordenes, emails de usuarios. Mientras mas contexto, mas rapido puedes reaccionar