WhatsApp Business API para acuse de soporte — reacción y confirmación de lectura
Este escenario combina sendReaction y readMessage durante la ventana de atención al cliente de 24 horas.
Descripción del caso de uso
Este escenario combina sendReaction y readMessage durante la ventana de atención al cliente de 24 horas. Una reacción de pulgar arriba en el id del mensaje entrante señala acuse sin otra burbuja de texto.
Ejemplo de plantilla
Tu mensaje fue registrado — estamos preparando una respuesta detallada.

Cuándo usarlo
Usa este escenario cuando llega un mensaje del cliente en una sesión de soporte de WhatsApp abierta y necesitas que sepa que fue visto antes de que la respuesta completa esté lista. Encaja con desarrolladores que integran bots de soporte, equipos pequeños que atienden colas de chat y agencias que pulen la UX de soporte al cliente sin sumar otra burbuja de texto por cada acuse.
Flujo de trabajo
- Estado registrado
Llega un mensaje del cliente vía webhook con su id de mensaje.
status:"read" - Construir y enviar
Tu backend envía una reacción de pulgar arriba citando ese id.
POST/send_reaction - Capturar evento
readMessage marca el mensaje entrante como leído.
phone:"+…" - Entregado
El cliente ve el acuse mientras se prepara la respuesta detallada.
entregado

Implementación técnica
Requisitos previos
- Clave API de 1MSG · Cómo obtener la clave API
- Cuenta de WhatsApp Business · Cómo conectar WABA
- Ventana de sesión de 24 horas abierta · Cómo funciona la ventana de 24 horas
- Opt-in del cliente · Cómo gestionar el consentimiento
- Endpoint de webhook · Cómo configurar webhooks
Ejemplos de código
#!/usr/bin/env bash
set -euo pipefail
# === Configuration (replace "___" placeholders) ===
API_BASE_URL="https://api.1msg.io" # production 1MSG API base URL
CHANNEL_ID="___" # channel ID from 1MSG dashboard
API_TOKEN="___" # channel JWT token (Bearer)
# === Test data ===
TEST_PHONE="___" # client phone in international format
INBOUND_MESSAGE_ID="___" # inbound message ID for reaction/read
PHONE_NORM="$(printf '%s' "$TEST_PHONE" | tr -cd '0-9')"
REACTION_URL="${API_BASE_URL%/}/${CHANNEL_ID}/sendReaction"
read -r -d '' PAYLOAD <<JSON || true
{
"phone": "${PHONE_NORM}",
"body": "👍",
"quotedMsgId": "${INBOUND_MESSAGE_ID}"
}
JSON
RESPONSE="$(curl -s -w '\n%{http_code}' -X POST "$REACTION_URL" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${API_TOKEN}" \
-d "$PAYLOAD")"
HTTP_CODE="$(printf '%s' "$RESPONSE" | tail -n1)"
BODY="$(printf '%s' "$RESPONSE" | sed '$d')"
case "$BODY" in
*'"sent":true'*) ok=1 ;;
*) ok=0 ;;
esac
if [ "$HTTP_CODE" -lt 200 ] || [ "$HTTP_CODE" -ge 300 ] || [ "$ok" -ne 1 ]; then
echo "$BODY" >&2
exit 1
fi
READ_URL="${API_BASE_URL%/}/${CHANNEL_ID}/readMessage"
read -r -d '' SECONDARY_PAYLOAD <<JSON || true
{ "messageId": "${INBOUND_MESSAGE_ID}" }
JSON
READ_RESPONSE="$(curl -s -w '\n%{http_code}' -X POST "$READ_URL" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${API_TOKEN}" \
-d "$SECONDARY_PAYLOAD")"
READ_CODE="$(printf '%s' "$READ_RESPONSE" | tail -n1)"
READ_BODY="$(printf '%s' "$READ_RESPONSE" | sed '$d')"
case "$READ_BODY" in
*'"result":"success"'*) read_ok=1 ;;
*) read_ok=0 ;;
esac
if [ "$READ_CODE" -lt 200 ] || [ "$READ_CODE" -ge 300 ] || [ "$read_ok" -ne 1 ]; then
echo "$READ_BODY" >&2
exit 1
fi
echo "Message sent to client."
Respuesta y estado de entrega
HTTP 2xx y JSON "sent": true significan que 1MSG aceptó el mensaje para envío — no que ya llegó al teléfono del cliente. Guarda el campo id (tipo wamid.…) para correlacionar los callbacks de entrega.
{
"sent": true,
"id": "wamid.HBgLMzgwNjM5...",
"message": "Message accepted for delivery"
}sentAceptado para envío — aún no en el teléfono del cliente
idGuárdalo; los callbacks de entrega y
hookInfose basan en él
La entrega llega después, como un callback aparte. Registra un webhook (POST …/webhook) y 1MSG enviará las actualizaciones de estado a tu endpoint HTTPS en un payload hooks[] de nivel superior.
{
"hooks": [
{
"id": "gBGGeSaGViBfAgnlzOSHEwK9O6F",
"type": "message",
"status": "sent",
"timestamp": "1654864094",
"recipient_id": "556123122026"
}
]
}statussent,delivered,read— o un estado de fallo cuando apliqueidCorrelaciona el callback con el
iddevuelto por el envíotimestampSegundos Unix, como cadena
Si prefieres no recibir callbacks, consulta GET {base}/{channel}/hookInfo?messageId=<id> en su lugar. En la práctica la entrega suele completarse en segundos — pero el contrato de la API no lo garantiza, así que nunca bloquees un flujo esperándola.
Errores frecuentes
| Estado | Respuesta | Causa |
|---|---|---|
| 200 | Message was not sent: empty body | Falta body en la petición. |
| 200 | Message was not sent: provide chatId, phone, bsuid, or username | Ningún destinatario que el canal pudiera resolver. |
| 200 | wrong file | El archivo no se pudo descargar ni subir — URL inalcanzable o base64 inválido. |
| 403 | access denied | El token es incorrecto, o pertenece a otro canal que el de la URL. |
| 200 | Message was not sent: filename | sendFile sin filename: el archivo no tiene extensión que enviar. |

