---
title: >-
  Build a WhatsApp conversation interface on Sautikit: one endpoint out, one
  webhook in
description: >-
  Send WhatsApp messages with one REST call and receive every reply and delivery
  status on your webhook. Two-way WhatsApp messaging on Sautikit.
summary: >-
  Sautikit's WhatsApp messaging is a clean pass-through: POST to send, every
  inbound message and delivery status lands on your signed webhook. Enough for a
  support inbox, order bot, or booking flow.
date: 2026-07-30T00:00:00.000Z
type: blog
---


## Summary

WhatsApp messaging on Sautikit is a pass-through, and that is the whole pitch. You send a message with one REST call — `POST https://api.sautikit.com/v1/whatsapp/messages` — and everything that comes back travels to you: every customer reply, every delivery status from sent to delivered to read, arriving on your own webhook in real time, signed so you can verify it. Message in, your code decides, one call replies. That loop is the entire programming model, and it is enough to build a support inbox, an order-tracking bot, a booking flow, or reminders customers can actually answer — on your stack, in your language, with your data.

## The channel your customers never leave

For many African businesses, WhatsApp is not a channel. It is *the* storefront. The catalogue is a pinned image, the checkout is a voice note, the CRM is a scroll through last month's chats. Customers reach for it before they reach for your app, your website, or your phone line — because it is already open, already paid for, and already where their family and their chama and their landlord live.

The problem was never demand. The problem was that the conversation lived inside one employee's handset. No API surface, no routing, no record your systems could see. The business's most important channel was also its least programmable one.

Sautikit closes that gap without inventing a platform you have to move into. Connect your WhatsApp Business account to your Sautikit number and the chat becomes an interface your own software drives.

## The loop: message in, your code decides, one call out

There are exactly two moving parts.

**Outbound is one HTTP request.** `POST https://api.sautikit.com/v1/whatsapp/messages` with a recipient and a body, authenticated with your API key. No session objects to manage, no connection to keep warm.

**Inbound is your webhook.** When a customer writes to your number, Sautikit delivers a `whatsapp.event.received` event to an endpoint you control — and the body is exactly what WhatsApp emitted, byte for byte. An inbound text, a voice note, an image, a delivery status moving through sent, delivered, read: they all arrive on the same event, unfiltered and untranslated, the moment they happen. Nothing is reshaped into a vendor schema you then have to learn on top of WhatsApp's. Every delivery is signed, so your handler can verify it came from Sautikit before acting — the same [signature discipline](/blog/webhook-signature-verification) you should demand of any webhook producer.

That is the whole model. There is no Sautikit inbox your team has to adopt, no widget to embed, no rules engine to configure. Your webhook receives the message, your code decides — look up the order, check the calendar, ask a human — and one API call replies. The logic lives where your logic already lives.

Here is the loop in its entirety — an Express webhook that answers order-status questions:

```js
import express from "express";

const app = express();
app.use(express.json());

app.post("/webhooks/whatsapp", async (req, res) => {
  res.sendStatus(200); // acknowledge first, work after

  // The body is WhatsApp's own payload, passed through untouched.
  const msg = req.body.messages?.[0];
  if (msg?.type !== "text") return; // statuses etc. arrive here too

  const from = msg.from;
  const order = await findOpenOrder(from); // your database

  const reply = order
    ? `Habari! Order ${order.ref} is ${order.status}. ` +
      `Expected delivery: ${order.eta}.`
    : "Karibu! Send your order number and I'll check on it.";

  await fetch("https://api.sautikit.com/v1/whatsapp/messages", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.SAUTIKIT_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ to: from, text: reply }),
  });
});
```

Twenty lines, and your WhatsApp number answers order questions at 11 pm without waking anyone. Swap the middle for your own logic and the same skeleton becomes a support triage bot, a booking assistant, or a delivery coordinator.

## Why pass-through beats a platform

Most WhatsApp tooling wants to be your new home. It arrives with an inbox your agents must log into, a bot builder with its own idea of logic, a contacts database that duplicates your CRM, and a pricing page that scales with seats rather than usage. You do not integrate those products — you move into them, and your customer data moves with you.

The pass-through design is the opposite bet. Sautikit carries the messages and gets out of the way. Your order state stays in your database, your business rules stay in your codebase, your conversation logic is a function you can unit-test, and swapping a human for a bot — or a bot for a human — is a code change, not a platform decision. When the flow needs something the chat cannot do alone, you reach for the rest of your stack the way you always do: call your own services, write your own tables, emit your own events.

It also means WhatsApp is not a special case in your architecture. A message event looks and behaves like the other webhooks your system consumes — signed, retried, verifiable. The channel is new; the engineering is the engineering you already trust.

## Delivery receipts you can build on

SMS taught a generation of developers to fire and forget, because the network told you nothing. WhatsApp tells you everything, and Sautikit passes it through: each message you send reports back as it is accepted, as it lands on the handset, and as the customer reads it.

That last signal changes product design. *Read but not answered* is a state SMS never had — and it is exactly the state a collections workflow, a delivery confirmation, or a sales follow-up wants to branch on. Escalate the unread reminder to a voice call. Suppress the nudge to someone who read the message two minutes ago. Your webhook sees the transition the moment it happens, so the decision is yours to automate.

Read receipts run the other way too: your application can mark customer messages as read via the API, so the person on the other end sees the blue ticks and knows the business is on it — even when "the business" is a script.

## Templates, records, and starting the conversation

Customers can message you any time, and inside the service window you reply freely. To *start* a conversation — a delivery update, an appointment reminder, a payment confirmation — you send an approved template message through the same endpoint. Templates are the handshake that keeps WhatsApp spam-free, and they make business-initiated flows first-class: notify first, then hold a real two-way conversation as the customer replies.

And because every message streams to your webhook as it happens, the system of record is yours. Store the thread in your own database, feed it to your support dashboard, pipe it into your analytics — your data, in your schema, on your infrastructure from the first message. No vendor inbox holds your customer conversations hostage, and no export button stands between you and your own audit trail.

## One number, the whole conversation

The number carrying these messages is not messaging-only. The same WhatsApp connection carries voice: the call button in your chat rings your Sautikit number over data, and everything the platform does with a call — routing, recording, [AI agents that answer and hold a real conversation](/blog/ai-agents-answer-your-inbound-calls) — applies to WhatsApp calls too. A support thread that gets complicated can end in a tap-to-call button; the call that follows is the same customer, on the same number, in the same system.

And when the conversation needs structure instead of prose — an address, a booking slot, a form's worth of fields — [WhatsApp Forms](/blog/whatsapp-forms-in-chat) put native multi-step screens inside the chat and deliver the answers to the same webhook as clean structured data.

Messaging, calling, forms: one number, one API key, one webhook loop your team already understands.

## What developers actually build with this

The pass-through design means the interesting part is yours. Some shapes we see working:

- **A support inbox on your own stack.** Inbound messages flow into the tooling you already have; agents reply through the API; the customer never knows or cares what is behind the green chat.
- **An order-tracking bot** like the one above — the highest-volume, lowest-stakes questions answered instantly, humans reserved for exceptions.
- **A booking flow.** Reminder goes out as a template; the customer replies to confirm or reschedule; your calendar updates without a phone call.
- **Reminders people can answer.** The difference between a notification and a conversation is that a conversation has a reply path. "Your instalment is due Friday — reply 1 to confirm, 2 to talk to someone" works when the reply actually reaches your code.

None of these require a platform migration. They require a webhook route and an afternoon.

And when the conversation itself is the hard part — open-ended questions, multiple languages, context that spans the whole thread — Sautikit's managed AI agents can hold the WhatsApp conversation for you: point an agent at your number's messages and it replies in a real back-and-forth, grounded in your business context, escalating to a human with the full history when it should. The webhook loop is the floor, not the ceiling.

## Start with a number

Claim a Sautikit number online — [from KES 116 per month in Kenya](/pricing), activated instantly, wallet topped up via M-Pesa — connect your WhatsApp Business account from the console, and point the webhook at your endpoint. The API reference and event schemas are on [/developers](/developers), and the Node SDK `@sautikit/node` is on npm when you want typed calls instead of raw fetch.

Your customers are already in the chat. Put your software in there with them — [sautikit.com](https://sautikit.com).