The drop-off rates were painful. Transactional SMS in India gets dumped into the promotional inbox by modern phone dialers, carrier-level DLT scrubbing templates cause silent delivery drops, and patients rarely read them. In dental outpatient care, a missed 45-minute root canal slot burns chair time that cannot be recovered.

We rebuilt our notification pipeline from scratch around the official WhatsApp Business Cloud API. Here is the technical architecture, webhook handling, and concurrency safeguards we put in place.

The Bottlenecks of WhatsApp Cloud API

Unlike sending a simple HTTP POST to an SMS gateway, WhatsApp enforces strict operational constraints:

1. Pre-approved Message Templates: You cannot send arbitrary strings outside an open 24-hour service window. Every notification template must be registered, categorized (Utility, Marketing, or Authentication), and approved with strict variable placeholders.

2. Asynchronous Delivery States: An HTTP 200 from the Meta Graph API only confirms that Meta accepted your payload. It does not confirm delivery to the handset, let alone whether the patient read it.

3. Webhook Retries and Idempotency: Meta webhooks retry aggressively if your endpoint responds with anything other than a fast 200 OK, or if response times exceed three seconds.

2. Architecture: Edge Workers and Decoupled Queues

To keep web latency negligible for front-desk staff booking appointments, we separated the appointment creation flow from message dispatch using background queues on Cloudflare Workers and PostgreSQL.

1. Front-Desk Browser: Staff schedules an appointment via the clinic dashboard.

2. Appointment Service (REST API): Persists the appointment to Postgres with status scheduled.

3. Notification Queue Worker: Triggers via internal event, formats the template, and calls the Meta Graph API.

4. Meta Cloud Infrastructure: Dispatches the message directly to the patient on WhatsApp.

5. Inbound Webhook Worker: Ingests asynchronous status callbacks (sent, delivered, read, failed) from Meta.

6. Event Store (Postgres): Updates the delivery ledger and refreshes front-desk delivery receipts in real time.

3. Handling Webhook Webhook Verifications and Callbacks

Meta requires a verification handshake using a challenge token during setup, followed by signed POST payloads for message status updates.

Here is a minimal TypeScript handler showing how we verify incoming webhook events and return an immediate 200 OK before kicking off background processing:

import { NextRequest, NextResponse } from "next/server";

export async function GET(req: NextRequest) { const { searchParams } = new URL(req.url); const mode = searchParams.get("hub.mode"); const token = searchParams.get("hub.verify_token"); const challenge = searchParams.get("hub.challenge");

if (mode === "subscribe" && token === process.env.WHATSAPP_VERIFY_TOKEN) { return new NextResponse(challenge, { status: 200 }); } return new NextResponse("Forbidden", { status: 403 }); }

export async function POST(req: NextRequest) { const body = await req.json();

// Return 200 immediately so Meta doesn't queue retries // Process the status updates asynchronously const entry = body.entry?.[0]?.changes?.[0]?.value;

if (entry?.statuses) { for (const status of entry.statuses) { await updateMessageStatus(status.id, status.status, status.timestamp); } }

return NextResponse.json({ success: true }, { status: 200 }); }

4. Managing Idempotency to Prevent Spamming Patients

One catastrophic bug in automated messaging is duplicate delivery. If an edge worker times out during a network stutter and retries a reminder, a patient might receive four identical reminder pings within two minutes.

We enforce idempotency at the database layer using a unique composite index:

SQL create table public.notification_dispatches ( id uuid primary key default gen_random_uuid(), appointment_id uuid references public.appointments(id) on delete cascade, notification_type text not null, -- 'booking_confirmation', 'reminder_24h', 'reminder_4h' wa_message_id text unique, status text not null default 'queued', dispatched_at timestamptz default now(), constraint uq_appointment_notification_stage unique (appointment_id, notification_type) );

By constraining (appointment_id, notification_type), the worker cannot issue duplicate messages for the same trigger stage. If a cron job or webhook fires twice, the database constraint rejects the second write before any HTTP call reaches Meta.

5. Real-Time Patient Confirmations

Automating reminders is only half the battle. When patients reply to confirm or request a reschedule, we route inbound webhook messages into the clinic's front-desk dashboard in real time.

If a patient replies with "Confirm", our webhook parser updates the chair schedule status to confirmed immediately, giving receptionists a live view of chair utilization without manual follow-up calls.

Shifting to native WhatsApp workflows reduced no-show rates in our pilot clinics by roughly 28%. The initial overhead of template approvals and webhook state synchronization pays for itself once appointment pipelines run on complete autopilot.