How to send WhatsApp messages programmatically (with code)

Sending a WhatsApp message from code is, at the core, a single HTTP POST. The complexity isn't the request — it's the rules around it. This guide covers both: the call itself, and the things that make it actually deliver in production.

The core request

Every WhatsApp send is a POST with a bearer token and a JSON body naming the recipient and the content. With walpio's Cloud-API-compatible endpoint it looks like this:

curl -X POST https://api.walpio.com/v1/messages \
  -H "Authorization: Bearer wp_live_····" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "9715XXXXXXXX",
    "type": "text",
    "text": { "body": "Your order is out for delivery today." }
  }'

A success returns the accepted message and an id you can track:

{
  "messaging_product": "whatsapp",
  "messages": [{ "id": "wamid.HBgL..." }],
  "walpio": { "id": "f3a1c2…", "via": "text" }
}

The part that bites: the 24-hour window

That plain-text send only works if the customer messaged you in the last 24 hours. Outside that window, WhatsApp requires an approved template. If you build directly against Meta, your code has to track each customer's last-inbound time, decide per send whether to go free-form or template, and construct the template payload. Get it wrong and messages vanish.

With walpio the same call above works whether the window is open or closed — if it's closed, walpio wraps your text into your approved template automatically and tells you via "via": "template" in the response. One endpoint, no window branching in your code.

Handle errors like an adult

• 4xx — permanent. Don't retry (bad number, policy rejection, no fallback template).
• 5xx — transient. Safe to retry with backoff.

Predictable error semantics mean your retry logic stays simple and you don't accidentally double-send.

Know what happened: delivery status

A 200 means “accepted,” not “read.” WhatsApp reports the real journey — sent, delivered, read, failed — asynchronously via webhooks. See delivery statuses and webhooks for how to consume them. walpio records the full timeline per message so you can query it or watch it in the dashboard.

Build vs buy

You can build all of this — the window tracking, template fallback, webhook signature verification, status timeline, rate limiting — against Meta directly. Or you can POST to one endpoint and get it handled. That's the trade walpio offers: your own Meta number, a Cloud-API-compatible surface, and the plumbing done.