Registra mensajes de WhatsApp en Airtable y envía desde una base

¿Por qué Airtable no puede recibir webhooks de WhatsApp directamente?

Porque Meta comprueba el destino antes de entregar nada. Envía una petición GET con un valor de desafío y espera recibir ese mismo valor como cuerpo de la respuesta. El trigger When webhook received de Airtable solo acepta peticiones POST y responde con su propio JSON fijo, así que la comprobación no puede pasar y Meta nunca empieza a entregar.

La solución es un paso intermedio. Un nodo Webhook de n8n gestiona la verificación y recibe cada mensaje, y el nodo de Airtable de n8n añade una fila: remitente, nombre de perfil, texto, id del mensaje, marca de tiempo y el phone number id receptor. La misma estructura sirve en Make o Zapier.

El paso intermedio tiene un segundo beneficio. El trigger de webhook de Airtable admite cinco peticiones por segundo, y una herramienta de workflows puede poner en cola una ráfaga que de otro modo sería rechazada.

¿Cómo se envía una plantilla de WhatsApp desde una base de Airtable?

Con una automatización cuya acción sea Run a script. El trigger puede ser un registro que entra en una vista, un campo que cambia o un botón pulsado. El script lee el teléfono y los campos del registro con input.config() y llama con fetch al endpoint messages de la Cloud API. Los scripts de automatización de Airtable se ejecutan en el servidor, así que no hay restricciones del navegador de por medio.

Guarda el token de acceso como secreto en el editor de scripts y no en el código. Airtable oculta los secretos en la salida de la consola y solo deja editar el script a quienes tienen acceso a todos sus secretos.

Usa una plantilla para cualquier mensaje que el cliente no haya provocado en las últimas 24 horas, ya que el texto libre solo se entrega dentro de esa ventana. El script puede escribir en el registro el id del mensaje devuelto, lo que vincula el envío con la fila.

const { phone, name } = input.config();
const token = input.secret("WHATSAPP_TOKEN");
const res = await fetch(
  "https://graph.facebook.com/v23.0/<PHONE_NUMBER_ID>/messages",
  {
    method: "POST",
    headers: { Authorization: "Bearer " + token, "Content-Type": "application/json" },
    body: JSON.stringify({
      messaging_product: "whatsapp",
      to: phone,
      type: "template",
      template: {
        name: "order_ready",
        language: { code: "en" },
        components: [{ type: "body", parameters: [{ type: "text", text: name }] }],
      },
    }),
  },
);
output.set("result", await res.json());

¿Cómo debe ser la tabla de mensajes?

Una fila por mensaje, con el id del mensaje de WhatsApp como campo principal. Meta reintenta las entregas que cree fallidas, y un workflow que busca el id antes de añadir nunca escribe el mismo mensaje dos veces.

Mantén un campo de dirección con inbound y outbound. En un número con Coexistencia, las respuestas que el equipo escribe en la app de WhatsApp Business llegan al mismo webhook como eventos smb_message_echoes, y registrarlas como filas outbound da a la base la conversación completa y no solo un lado.

Vincula cada mensaje a una tabla Contacts con clave en el teléfono con solo dígitos, que es la forma en que Meta lo envía. Un rollup muestra entonces la hora del último mensaje entrante por contacto, y ese único campo es lo que necesita una automatización para decidir entre texto libre y una plantilla.

Errores comunes

• Poner una URL de webhook de Airtable como destino del número. Solo acepta POST, el GET de verificación de Meta falla y no se entrega nada.
• Pegar el token de acceso en el cuerpo del script. Guárdalo como secreto del script para que no aparezca en el código ni en los logs.
• Enviar texto libre desde una automatización de registros a alguien que no ha escrito en 24 horas. Solo se entrega una plantilla aprobada.

Preguntas frecuentes

Sigue leyendo