WhatsApp messaging API
Send WhatsApp. Read the reply.
One endpoint to send, a signed webhook the moment somebody answers, and an inbox for whoever is going to type back.
No password needed — we can mail you a sign-in link.
$ curl https://sendbu.com/v1/messages \
-H "Authorization: Bearer sk_live_…" \
-H "Idempotency-Key: order-8842-shipped" \
-d '{ "channel_id": "6b1f0c4e-9a2d-4f77-bd31-0c5a…",
"to": "+15551234567",
"type": "text",
"text": { "body": "Your order has shipped." } }'
< 202 Accepted
{ "id": "0f9c7a55-3d84-4b1e-9a60-27ce1f0b4d93",
"status": "queued" }/v1, or in the Inbox.The half that is usually missing
A reply is a message too.
Most WhatsApp APIs are a send button. When somebody answers, the answer has to land somewhere — in your code as an event, and in front of whoever is going to type back.
Hi — has my order shipped yet?
18:52It went out this morning. Tracking is on its way to you now.
18:53 · sentPerfect, thank you!
18:53- It arrives as an event.
message.receivedcarries the sender, the text and WhatsApp’s own timestamp — not an id you have to fetch. - It is readable afterwards.
GET /v1/messagesand/v1/conversationspage through everything either way, so a missed webhook is not a lost message. - Somebody can answer it. The Inbox in the panel is a real reply box, and a support agent does not need an admin account to use it.
What is not built yet
Media. A photo, a voice note or a document sent to your number is dropped rather than shown as something it is not. The Meta Cloud API. Today a channel is a phone of yours holding the session, the way WhatsApp Web links a device. Billing. No card, no price list, no invoice — a plan is set by hand.
Everything else on this page runs in production. The reference keeps the same list, and is written from the code that serves it.
Create the account. Mint the key.
No password, no card. Point a client at /v1 and watch it authenticate — and you are already set up for the day the channel screens land.