WhatsApp Business API for support acknowledgement — reaction and read receipt

Use case overview

This scenario combines sendReaction and readMessage during the 24-hour customer service window. A thumbs-up reaction on the inbound message id signals acknowledgement without another text bubble.

Template example

Your message was noted — we are preparing a detailed reply.

Reaction emoji and read receipt target the inbound message id from the webhook payload.

When to use it

• support ux polish

Business value

• Inbound client message arrives via webhook with message id
• sendReaction adds a thumbs-up emoji on the quoted inbound message
• readMessage marks the inbound message as read in WhatsApp
• Client perceives fast acknowledgement without extra text spam
• Agent or automation continues with the detailed response when ready

Workflow

1. A client message arrives via webhook with its message id.
2. Your backend sends a thumbs-up reaction quoted to that id.
3. readMessage marks the inbound message as read.
4. The client sees acknowledgement while the detailed reply is prepared.
5. Delivery progress is reported asynchronously — typically sent, then delivered (or failed/undelivered).
6. Your system receives status via webhook (hooks[]) or polls delivery status and handles failures if needed.

Technical implementation

Prerequisites

• An open WhatsApp session window and inbound webhook that provides the message id.
• 1MSG channel with sendReaction and readMessage access.

Code examples

#!/usr/bin/env node

// === Configuration (replace "___" placeholders) ===
const API_BASE_URL = "https://api.1msg.io"; // production 1MSG API base URL
const CHANNEL_ID = "___";                   // channel ID from 1MSG dashboard
const API_TOKEN = "___";                    // channel JWT token (Bearer)



// === Test data ===
const TEST_PHONE = "___";            // client phone in international format
const INBOUND_MESSAGE_ID = "___";         // inbound message ID for reaction/read

function normalizePhone(phone) {
  return String(phone).replace(/\D/g, "");
}

async function sendReactionAndRead({ phone, messageId }) {
  const reactionUrl = `${API_BASE_URL}/${CHANNEL_ID}/sendReaction`;
  const requestBody = {
    phone: normalizePhone(phone),
    body: "👍",
    quotedMsgId: messageId,
  };

  const reactionRes = await fetch(reactionUrl, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${API_TOKEN}`,
    },
    body: JSON.stringify(requestBody),
  });

  const reactionRaw = await reactionRes.text();
  let reactionData;
  try {
    reactionData = JSON.parse(reactionRaw);
  } catch {
    reactionData = null;
  }

  if (!reactionRes.ok || !reactionData || reactionData.sent !== true) {
    console.error("Send failed.");
    console.error(reactionRaw);
    process.exit(1);
  }


  const readUrl = `${API_BASE_URL}/${CHANNEL_ID}/readMessage`;
  const secondaryRequestBody = { messageId };

  const readRes = await fetch(readUrl, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${API_TOKEN}`,
    },
    body: JSON.stringify(secondaryRequestBody),
  });

  const readRaw = await readRes.text();
  let readData;
  try {
    readData = JSON.parse(readRaw);
  } catch {
    readData = null;
  }

  if (!readRes.ok || !readData || readData.result !== "success") {
    console.error("Send failed.");
    console.error(readRaw);
    process.exit(1);
  }
  console.log("API response:", readRaw);


  console.log("Message sent to client.");
  console.log("API response:", reactionRaw);
  return reactionData;
}

if (require.main === module) {
  sendReactionAndRead({ phone: TEST_PHONE, messageId: INBOUND_MESSAGE_ID }).catch((err) => {
    console.error("Execution failed:", err.message);
    process.exit(1);
  });
}

module.exports = { sendReactionAndRead };

Immediate API response (synchronous)

• HTTP 2xx and JSON "sent": true mean 1MSG accepted the message for sending — not that it already reached the customer's phone.
• Save the `id` field from the response (value looks like wamid.…). Use it to correlate delivery callbacks or polling.
• The response may also include message and description — informational only.

Delivery status (asynchronous)

• Register a webhook (POST …/webhook) so 1MSG POSTs delivery updates to your HTTPS endpoint in a separate `hooks[]` payload (sent, delivered, read, or failed/undelivered when applicable).
• Optionally poll: GET {base}/{channel}/hookInfo?messageId=<id from sendTemplate>.
• In practice, delivery often completes within a few seconds — but that is not guaranteed by the API contract.

Common errors

• Session window closed (no client message within 24 hours)
• Invalid or non-normalized phone number
• Missing or invalid message body / media URL
• Delivery failure — check status webhook and retry policy

FAQ

• Do I need a template? No — this scenario uses a session message inside the 24-hour customer service window.
• When does the session window close? If the client has not written or replied within 24 hours, sendMessage will fail until a template reopens the chat.
• How do I check delivery? sent: true only confirms acceptance. Track delivery via webhook hooks[] or polling.
• What if the message is not delivered? Log the failed/undelivered hook, verify the session window, then retry or use a template.
• Can I connect this to my CRM or backend? Yes — trigger the API call from your inbound webhook or workflow engine.

Related

• Knowledge base
• Creating a template
• Sending a template
• SDK