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.

WhatsApp Business API for session reply — request additional information

This scenario sends a free-text WhatsApp message with sendMessage inside the 24-hour customer service window.

Try the demo View code example

Use case overview

This scenario sends a free-text WhatsApp message with sendMessage inside the 24-hour customer service window. Use it after an inbound webhook event when you already have an open session and must request missing ticket details.

Template example

To continue resolving ticket {{1}}, please send {{2}}.

{{1}}
support ticket number
{{2}}
what you need from the client (photo, document, clarification)

WhatsApp Business API for session reply — request additional information

When to use it

Reach for this scenario when an inbound webhook shows the client already wrote in WhatsApp and your support team needs one specific photo, document, or clarification before closing the ticket. It fits helpdesk follow-ups where the 24-hour session window is open and a template would add cost and friction to an ongoing dialog.

No template spend on open tickets

sendMessage sends free-text inside the 24-hour customer service window, so you ask for missing details without paying for a template on a conversation the client already started.

Faster ticket resolution

Two body variables carry the ticket number and the exact item you are waiting for, so the client knows what to send back without opening email or repeating the issue.

Less agent back-and-forth

Your backend maps the inbound webhook to the ticket and fills both placeholders before sendMessage fires, so the agent does not retype the request in chat.

Reply stays in the same thread

The client receives the request in the open WhatsApp session and can attach the photo or document in the same chat, where your webhook picks up the inbound reply for the helpdesk.

Workflow

Status tracked
An inbound client message arrives via webhook.
status: "read"
Capture event
Your backend maps the chat to a ticket and determines the missing detail.
POST /sendMessage
Build & send
A session text message is sent referencing the ticket and the awaited item.
POST /sendMessage
Delivered
The client replies with the requested material in the same session.
delivered

Technical implementation

Prerequisites

1MSG API Key · How to get API Key
WhatsApp Business account · How to Connect WABA
Open 24-hour session window · How the 24-hour window works
Customer opt-in · How to Manage Customers Consent
Webhook endpoint · How to Set Up Webhooks

Code examples

#!/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 · requires open 24-hour session window
TEST_TICKETNUMBER="___"         # {{1}} ticket number
TEST_AWAITEDITEM="___"         # {{2}} awaited item

PHONE_NORM="$(printf '%s' "$TEST_PHONE" | tr -cd '0-9')"

for pair in "CHANNEL_ID=$CHANNEL_ID" "API_TOKEN=$API_TOKEN" "TEST_PHONE=$TEST_PHONE" \
            "TEST_TICKETNUMBER=$TEST_TICKETNUMBER" \
            "TEST_AWAITEDITEM=$TEST_AWAITEDITEM"; do
  val="${pair#*=}"
  if [ -z "$val" ] || [ "$val" = "___" ]; then
    echo "Missing configuration value: ${pair%%=*}" >&2
    exit 1
  fi
done

if [ -z "$PHONE_NORM" ]; then
  echo "Error: phone number has no digits after normalization" >&2
  exit 1
fi

URL="${API_BASE_URL%/}/${CHANNEL_ID}/sendMessage"

read -r -d '' PAYLOAD <<JSON || true
{
  "phone": "${PHONE_NORM}",
  "body": "To continue resolving ticket TKT-1024, please send a photo of the damaged item."
}
JSON

RESPONSE="$(curl -s -w '\n%{http_code}' -X POST "$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" -ge 200 ] && [ "$HTTP_CODE" -lt 300 ] && [ "$ok" -eq 1 ]; then
  echo "Message sent to client."
  echo "API response: $BODY"
else
  echo "Send failed. HTTP status: $HTTP_CODE" >&2
  echo "$BODY" >&2
  exit 1
fi

Response and delivery status

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 (looks like wamid.…) to correlate delivery callbacks.

200 OKResponse

{
  "sent": true,
  "id": "wamid.HBgLMzgwNjM5...",
  "message": "Message accepted for delivery"
}

sent
Accepted for sending — not yet on the customer's phone
id
Store it; delivery callbacks and hookInfo are keyed on this

Delivery itself arrives later, as a separate callback. Register a webhook (POST …/webhook) and 1MSG POSTs status updates to your HTTPS endpoint in a top-level hooks[] payload.

200 OKDelivery status webhook — payload you receive

{
  "hooks": [
    {
      "id": "gBGGeSaGViBfAgnlzOSHEwK9O6F",
      "type": "message",
      "status": "sent",
      "timestamp": "1654864094",
      "recipient_id": "556123122026"
    }
  ]
}

status
sent, delivered, read — or a failure status when applicable
id
Correlates the callback with the id returned by the send call
timestamp
Unix seconds, as a string

If you would rather not receive callbacks, poll GET {base}/{channel}/hookInfo?messageId=<id> instead. In practice delivery often completes within seconds — but the API contract does not guarantee it, so never block a flow waiting on it.

Common errors

Status	Response	Cause
200	Message was not sent: empty body	No body in the request.
200	Message was not sent: provide chatId, phone, bsuid, or username	No recipient the channel could resolve.
200	wrong file	The media could not be fetched or uploaded — not a reachable URL, not valid base64.
403	access denied	The token is wrong, or belongs to a different channel than the URL.
200	Message was not sent: filename	sendFile called without a filename, so the media has no extension to send.