Bot de Discord con IA: Interactions, ack en 3 segundos y cola

Un slash command no es un chat infinito. Discord te manda una Interaction y el reloj empieza: respuesta inicial en 3 segundos o el token queda inválido. Los followups valen 15 minutos. Eso está en Receiving and Responding, no es folklore de Discord.js.

El LLM no entra en esos 3 segundos de forma fiable. El patrón es el mismo que en Telegram: ack primero, agente después. El curso instalar un agente cubre el loop; aquí el borde es HTTP de Discord.

Qué llega

Una Interaction trae id, application_id, type, y casi siempre data (excepto PING). Slash commands incluyen los valores del usuario. User/Message commands traen el usuario o mensaje resuelto. Components identifican el botón o select.

type 1 = PING. Tu endpoint debe responder PONG (callback type 1). Si fallas el ping, Discord marca el endpoint muerto.

El reloj de 3 segundos

Docs: you must send an initial response within 3 seconds of receiving the event. If the 3 second deadline is exceeded, the token will be invalidated.

Opciones de callback que importan:

Type	Nombre	Qué ve el usuario
1	PONG	Nada; healthcheck
4	CHANNEL_MESSAGE_WITH_SOURCE	Mensaje ya
5	DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE	Loading; editas después
6	DEFERRED_UPDATE_MESSAGE	Components; sin loading

Para un agente: type 5, encola { interactionId, token, applicationId }, HTTP 200. Luego PATCH original response o followup dentro de 15 minutos.

Si metes await llm() en el handler, un cold start de 4 s = comando muerto. No hay retry amable: el usuario ve “esta interacción falló”.

Firma antes del JSON

Discord firma el body. Verifica antes de parsear negocio. Endpoint público sin verify = cualquiera dispara tu cola (y tu factura). Detalle de headers en la misma familia de docs de Interactions; el contrato mental: raw body + timestamp + firma. Un framework que re-serializa JSON rompe la firma — igual que Stripe.

No proceses data.options si la firma falla. Responde 401.

El agente no vive en el callback

app.post("/interactions", async (req, res) => {
  if (!verify(req)) return res.status(401).end();
  const body = req.body;
  if (body.type === 1) return res.json({ type: 1 });
  await queue.add("discord-agent", { token: body.token, id: body.id, data: body.data });
  return res.json({ type: 5 }); // deferred
});

El worker llama al modelo, tools, y edita la respuesta. El token es un secreto de corta vida: logs sí, prompts no. Prompt injection aplica: el texto del usuario en data es no confiable.

Checklist

• Endpoint HTTPS público; verify en el borde.
• PING → PONG sin cola.
• Slash → defer (5) + cola; LLM fuera del request.
• Editar original o followup < 15 min.
• Mensajes largos: Discord parte; no asumas 4096 de Telegram.
• allowed_mentions si el modelo cita @everyone.
• Intents privilegiados: no los pidas “por si acaso”. Interactions HTTP no sustituyen el Gateway si necesitas mensajes crudos de un canal.

Gateway vs HTTP: Interactions HTTP bastan para slash/components. Leer cada mensaje del servidor exige Gateway e intents. Empieza por HTTP.

Idempotencia: Discord puede reenviar. Dedup por id de la Interaction (snowflake) con SET NX unas horas. El ack type 5 dos veces es feo; el LLM dos veces es una factura.

FAQ

¿Puedo responder el mensaje del modelo en el mismo 200? Solo si el modelo ya terminó en <3 s. En producción, no.

¿El token sirve para otra app? No: es de esa interaction.

¿Ephemeral? Flag en el defer inicial. No lo cambias después (docs: el estado ephemeral no se cambia al editar).

¿n8n? Válido para un prototipo; el ack de 3 s sigue siendo tuyo. Si n8n tarda, Discord corta.

Verificado 2026-09-03 contra Discord Docs — Receiving and Responding (3 s, token 15 min, PING/PONG, deferred type 5).