Cómo publicar en Discord por API: webhook para publicar, bot para leer
En Discord se publica con un webhook y se lee con un bot. Son dos credenciales distintas de la misma aplicación, se consiguen en una sola autorización y funcionan por separado: si echan al bot del servidor, publicar sigue funcionando y solo se caen los comentarios y las estadísticas. Entender esa separación es la mitad de integrar Discord.
¿Con qué se publica en Discord por API: con un bot o con un webhook?
Con un webhook entrante, y se lee con el bot. No es una preferencia de estilo: cada credencial puede hacer cosas que la otra no.
| Webhook entrante | Bot | |
|---|---|---|
| Cómo se autentica | El token va en la URL (/webhooks/{id}/{token}) |
Cabecera Authorization: Bot <token> |
| Para qué sirve | Publicar mensajes en un canal | Leer hilos, reacciones y miembros |
| Con qué identidad aparece | La que le pongas: nombre y avatar de tu marca | El nombre y el avatar del bot |
| Alcance | Solo el canal para el que se creó | Todos los canales que vea en el servidor |
| ¿Caduca? | No | No |
La diferencia que importa es la tercera fila. Un mensaje publicado por webhook sale con el nombre y el avatar que tú le des; publicado por el bot, sale firmado por el bot. Es la diferencia entre un anuncio de la marca y «un bot ha escrito algo» — Discord le pone igualmente su etiqueta de aplicación al lado, pero el nombre y la foto son los tuyos.
La cuarta fila explica la otra mitad: el webhook solo puede escribir en su canal y no puede leer nada que no haya escrito él. Para los comentarios hace falta el bot.
Y hay una consecuencia deliberada de que sean independientes: si un administrador echa al bot del servidor, las publicaciones programadas siguen saliendo. Solo dejan de llegar los comentarios y el recuento de miembros.
¿Dónde están los comentarios de un mensaje de Discord?
En el hilo que cuelga de ese mensaje. Discord no tiene comentarios como tales: lo que se parece es un hilo (thread) abierto sobre un mensaje publicado, y los mensajes de dentro son las respuestas.
Esto trae un regalo para quien integra: el id del hilo es el id del mensaje. No hay un identificador nuevo que guardar ni que emparejar — con el id de la publicación ya se puede pedir el hilo. Es de las pocas cosas de esta red que salen más baratas de lo que parecían.
Lo que sí hay que filtrar es el ruido. Dentro de un hilo, Discord mete mensajes de sistema con id propio —«se ha creado un hilo», «fulano se ha unido»— y si no se descartan por su type, entran en la bandeja como filas vacías. Solo los tipos 0 (mensaje normal) y 19 (respuesta) son comentarios de verdad.
¿Por qué la aplicación de Discord tiene que ser tuya y no de la herramienta?
Porque el permiso de leer el texto de los mensajes se revisa por aplicación, no por servidor, y ese permiso es justo el que hace falta para tener comentarios.
MESSAGE_CONTENT es un intent privilegiado. Por debajo de 10.000 usuarios alcanzables —la suma de miembros de todos los servidores donde esté esa aplicación— se activa con un interruptor en el portal, sin revisión. Por encima hay que solicitarlo por escrito, con 90 días desde el aviso, y reaplicar cada año (política de intents privilegiados de Discord, consultada en agosto de 2026).
Ahí está el problema de una aplicación compartida entre clientes: un solo cliente con una comunidad de 12.000 miembros mete a toda la plataforma en ese ciclo de revisión anual, y el día que una renovación se atasque, la bandeja se queda muda para todos a la vez. Con la aplicación a tu nombre, el umbral es el de tu comunidad, la solicitud la firma quien tiene el caso de uso, y no se propaga a nadie.
Es la razón por la que en PlanVortex la aplicación de Discord la pone el cliente y no nosotros — la única red de las diez en la que es así. El precio es un paso manual de unos diez minutos; a cambio, los límites de Discord los marca tu comunidad y no una cola compartida.
Cómo crear la aplicación de Discord paso a paso
Cinco pasos en discord.com/developers/applications, y ninguno más:
- Crea la aplicación con New Application y ponle el nombre de tu marca. Es el nombre que verá quien instale el bot.
- En OAuth2, copia el Client ID y genera el Client Secret con Reset Secret. El secreto solo se enseña una vez.
- En Bot, genera el token con Reset Token. También se enseña una vez: cópialo antes de salir de la pantalla.
- En Bot, revisa tres casillas. Public Bot activado —si no, solo el dueño de la aplicación puede instalarlo—, Requires OAuth2 Code Grant desactivado —si está activado, el flujo de autorización se rompe— y Message Content Intent activado, en Privileged Gateway Intents.
Server Members IntentyPresence Intentno hacen falta. - En OAuth2 → Redirects, registra la URL de vuelta: la de tu panel seguida de
/connect/discord. Discord rechaza la autorización con Invalid OAuth2 redirect_uri si esa URL exacta no está en la lista, y si sirves el panel bajo tu propio dominio, la que hay que registrar es la tuya.
El paso 4 es el que ahorra el soporte. Las dos primeras casillas rompen el flujo con un error que no explica nada, y la tercera no rompe nada: simplemente hace que los comentarios lleguen en blanco.
¿Qué permisos hay que pedirle al bot?
Los mínimos para leer un hilo y responder en él. Discord codifica los permisos como un entero de bits que viaja en la URL de instalación, así que el número que pidas es el número que el usuario va a ver en la pantalla de Discord antes de aceptar. Conviene que sea corto de justificar.
| Permiso | Bit | Para qué |
|---|---|---|
VIEW_CHANNEL |
1.024 | Ver el canal y su hilo |
SEND_MESSAGES |
2.048 | Responder si el webhook fallara |
MANAGE_MESSAGES |
8.192 | Borrar el comentario de otra persona |
EMBED_LINKS |
16.384 | Previsualización de enlaces |
ATTACH_FILES |
32.768 | Adjuntar archivos |
READ_MESSAGE_HISTORY |
65.536 | Leer el hilo |
ADD_REACTIONS |
64 | Reaccionar |
CREATE_PUBLIC_THREADS |
2³⁵ | Abrir el hilo de la publicación |
SEND_MESSAGES_IN_THREADS |
2³⁸ | Escribir dentro del hilo |
Sumados dan 309.237.771.328, que es el entero que pide PlanVortex al instalar.
Dos avisos sobre esa tabla. El primero: READ_MESSAGE_HISTORY es el permiso que más se olvida, y sin él la lista de mensajes vuelve vacía en lugar de dar error — el mismo síntoma que el intent que falta, y por eso hay que descartar los dos. El segundo es para quien calcule el entero en JavaScript: CREATE_PUBLIC_THREADS es el bit 35 y SEND_MESSAGES_IN_THREADS el 38, así que combinarlos con | no funciona. Los operadores bit a bit de JavaScript truncan a 32 bits y 1 << 35 da 8. Hay que sumarlos, que con bits distintos da el mismo resultado y cabe de sobra en un número normal.
¿Qué límites tiene publicar en Discord?
Los de un mensaje, más los de caudal. Estos son los valores que PlanVortex valida en su integración con la API v10 (agosto de 2026):
| Límite | Valor |
|---|---|
| Texto de un mensaje | 2.000 caracteres |
| Adjuntos por mensaje | 10 |
| Peso por archivo, sin boost o nivel 1 | 8 MB |
| Peso por archivo, nivel 2 | 50 MB |
| Peso por archivo, nivel 3 | 100 MB |
| Publicaciones por canal | 5 cada 5 segundos |
Los 8 MB son el límite que más sorprende: un vídeo de 20 MB que en las otras redes se publica sin problema, aquí devuelve un 413. Y el nivel de boost del servidor solo se puede consultar con el bot dentro, porque viaja en el campo premium_tier del guild — sin bot, hay que asumir el suelo.
El límite de caudal es por canal y lo comparten todos los webhooks de ese canal, así que dos integraciones apuntando al mismo sitio se pisan entre ellas. Y hay un techo por encima que no aparece en ninguna documentación de límites: Discord cuenta las peticiones inválidas (401, 403 y 429) y a las 10.000 en 10 minutos Cloudflare corta el acceso por IP. Eso significa que un bug que falle en bucle no tumba una cuenta: tumba todas las que salgan de esa máquina. Merece la pena limitar el caudal total de salida por aritmética y no por confianza.
¿Qué no se puede hacer en Discord por API?
Tres cosas que conviene saber antes de prometerlas:
- Mensajes directos, no. Un bot no puede empezar una conversación privada con alguien que no la haya abierto antes, y leer los DMs entrantes exige una conexión WebSocket permanente contra el Gateway. Es un proceso siempre encendido, no una llamada REST.
- Ocultar un comentario, tampoco. Discord no tiene «ocultar»: se borra o se deja. Es la diferencia frente a Facebook, Instagram o YouTube, donde ocultar es una acción distinta de borrar.
- Notificaciones entrantes, tampoco. Los «webhooks» de Discord apuntan hacia Discord: sirven para escribir, no para que Discord te avise. Lo que avisa es el Gateway, que es otra vez el WebSocket permanente.
Nada de esto es un defecto de Discord — es una red pensada para comunidades en tiempo real, no para publicación programada, y la API refleja esa forma. Pero es lo que decide si tu integración puede prometer una bandeja de mensajes o solo una de comentarios.
En PlanVortex, Discord publica en canales de texto y trae los comentarios del hilo; no tiene bandeja de mensajes directos, y la ficha de la cuenta lo dice en lugar de dejar un hueco. Puedes ver qué hace cada red o los límites que publicamos por si integras contra nuestra API.
¿Se puede publicar en Discord solo con un bot, sin webhook?
Se puede, pero el mensaje sale firmado por el bot: su nombre y su avatar, no los de tu marca. El webhook entrante existe precisamente para eso — al crearlo puedes fijar el nombre y el avatar con los que aparece cada mensaje. Por eso PlanVortex publica por webhook y reserva el bot para leer. Además son independientes: el webhook no caduca y sigue funcionando aunque el bot salga del servidor.
¿Qué pasa si no activo el Message Content Intent?
Los comentarios llegan vacíos, no da error. Sin ese intent Discord responde 200 con el campo content en blanco en GET /channels/{id}/messages, así que la integración recibe una lista de mensajes sin texto y todo parece correcto. Es el fallo más caro de diagnosticar de esta red. Se activa en el portal, en Bot → Privileged Gateway Intents, y por debajo de 10.000 usuarios alcanzables se activa solo, sin revisión.
¿Cuántos caracteres y cuántos archivos admite un mensaje de Discord?
2.000 caracteres de texto y 10 adjuntos por mensaje. El peso de cada archivo depende del nivel de boost del servidor: 8 MB sin boost y con nivel 1, 50 MB con nivel 2 y 100 MB con nivel 3. El nivel solo se puede consultar con el bot dentro del servidor, porque viaja en el campo premium_tier del guild, así que sin bot hay que asumir el suelo de 8 MB.
¿Por qué la aplicación de Discord tiene que ser mía y no de la herramienta?
Porque el permiso de leer el texto de los mensajes se revisa por aplicación, no por servidor. Por debajo de 10.000 usuarios alcanzables se activa solo; por encima hay que solicitarlo por escrito y renovarlo cada año. Con una aplicación compartida, un solo cliente con una comunidad grande mete a toda la plataforma en ese ciclo de revisión. Con la aplicación a tu nombre, el umbral es el de tu comunidad y no se propaga a nadie.
¿Se pueden leer los mensajes directos de Discord por API?
No con este planteamiento. Un bot no puede iniciar una conversación privada con alguien que no la haya abierto antes, y recibir los mensajes directos entrantes exige mantener una conexión WebSocket permanente contra el Gateway de Discord. Eso es un proceso que vive siempre encendido, no una llamada REST, y es otra pieza de infraestructura. Por eso PlanVortex no ofrece bandeja de mensajes directos en Discord.