DEV Community: David Friedman

Handling WhatsApp Cloud API webhooks without losing your mind: echoes, retries, and the five ways a message lies to you

David Friedman — Sun, 30 Aug 2026 17:45:02 +0000

Handling WhatsApp Cloud API webhooks without losing your mind: echoes, retries, and the five ways a message lies to you

The previous post covered how my AI receptionist books appointments. This one is about the part of the system nobody photographs: the webhook, where Meta tells you what happened. Slowly. Twice. Occasionally in the wrong order.

The promise vs the delivery

The tutorial version of a WhatsApp integration: Meta POSTs you a message, you parse messages[0].text.body, you reply. Ship it Friday.

The production version is different. Your endpoint receives a payload with no message in it. Or the same message five times. Or a message you yourself sent. Or a status update for a message you never saw, from a sender whose WhatsApp ID has silently changed case. Each of these is a different 2am incident, and all five show up within your first month of real volume.

I learned each one the expensive way so you can learn it the cheap way. Here they are, ordered by blast radius.

1. Retries: the same webhook, five times

Meta's webhook delivery is at-least-once. If your endpoint doesn't answer 200 within a few seconds - cold start, a slow downstream call, a deploy, anything - Meta queues a redelivery. Network blip? Redelivery. Deploy restarting? Redelivery.

Now remember what the payload usually is. It's a customer asking to book something.

If you process it twice, your AI books Saturday twice, confirms twice, and the customer quietly concludes your receptionist is an over-caffeinated intern. So: dedupe on the platform message ID, with a TTL store - a Firestore doc with a TTL policy, a Redis SET NX EX, whatever you have. Check it before any business logic runs. First delivery is real, everything else is a log line.

POST /webhook
  → verify signature (X-Hub-Signature-256, HMAC of raw body)
  → extract every entry[].changes[].value
  → for each message: if seen(m.id) → skip
  → mark seen(m.id) BEFORE processing   ← not after
  → process

Look at where "mark seen" sits. Before processing. Not after.

I put it after, once. Two redeliveries landed a few milliseconds apart, both passed the check, both wrote to the database, and I owned a very apologetic conversation about a double-booked Saturday. If the write is after the check, two concurrent deliveries can both pass. And Meta does retry across regions concurrently.

2. Echoes: your own bot arrives through the front door

This is the sneakiest of the five. When your bot sends a message, WhatsApp also delivers that message back to your webhook, as if it were inbound. Your own reply, arriving through the front door like a stranger.

Naive code responds to it. And then you have a bot answering itself. I have watched two instances of my own bot exchange politeness spirals, only stopping when something hit a rate limit, while the customer watched the "typing..." indicator flicker like a haunted office.

Filter on the message source. Only process entries whose from is the customer's WhatsApp ID, and ignore anything arriving under the App ID your own sends go out through. Before dedupe, not after, because echoes also fan out on retries.

One counterintuitive note: the echo stream is secretly useful. It's a built-in delivery receipt for your own sends. Just don't build state on it until the filter is bulletproof - a conversation history that contains your bot's own messages looks identical to "the customer said this," and every downstream feature breaks at once.

3. Statuses are not messages, except when they arrive for ghosts

A statuses payload is delivery metadata: sent, delivered, read, failed. It references a message ID that should exist in your store.

Should.

During a webhook outage, a manual re-subscribe, or a number migration, statuses arrive for messages your system never stored. That's a ghost reference. And if your code assumes the lookup succeeds - or worse, throws a 500 when it doesn't - you've just told Meta to retry. Forever. A retry loop over a dead reference.

Accept the webhook with 200 and move on. A status for a ghost costs nothing to ignore. Crashing on it costs you the queue.

And persist read receipts properly, because they matter more than they look like they do. Suppressing a bot takeover when the human on your team is mid-conversation - that depends on knowing whose messages are being read, and when.

4. The 24-hour window, and the errors Meta doesn't advertise

Outside 24 hours from a customer's last message, you can't send free-form text. You send an approved template. Fine, you think. Except the failure isn't clean. The API accepts your call, Meta queues the message, and later a failed status arrives with error 131047 - re-engagement required.

Which means: your booking confirmation queue reported success. The customer received nothing. The only trace is a delayed status webhook that your older code treated as noise. I know, because that was my older code.

Parse statuses[].errors[] from day one. 131047 means send the template version instead - so actually send it, automatically. 131026 (undeliverable) usually means a genuinely dead line: mark the contact, stop spending effort on it. Each code class needs its own handling, and the default handler should never be "ignore."

5. Webhooks for conversations you're no longer in

This last one is business logic wearing a technical costume.

Human takes over a conversation in the shared inbox. Customer replies. Webhook fires. The bot answers too? Obviously not - there's a takeover flag. I use a 30 minute cooldown: long enough that the human clearly has the wheel, short enough that a forgotten conversation doesn't dead-end.

But flags rot, and the dangerous window isn't the one you're thinking about. It's this: the AI decides to send at 10:00:00, and a human replies to the same thread at 10:00:04. Your pre-send check happened before their reply landed.

So the check has to run immediately before every automated send, not just when the inbound message arrives. The webhook fires; the state of the conversation is the only truth. Same discipline as the dedupe - trust the flag, but read it fresh, every time.

Verify token, signatures, and the boring gate

Setup: Meta GETs you with hub.mode=subscribe and a hub.verify_token, you echo hub.challenge if the token matches. Every POST after that carries X-Hub-Signature-256, an HMAC-SHA256 of the raw body with your app secret.

Two details that bite:

Compute the HMAC on raw bytes. Before JSON parsing. Framework body parsers will happily consume the stream otherwise - both Express's body-parser and Next.js route handlers need explicit raw-body capture. I learned this from a signature check that passed locally and failed in staging, which is exactly the kind of sentence you never want to have to say out loud.

And compare timing-safe, not ===. If the signature fails, 401 immediately, and log the app ID - the most common cause is two Meta apps firing at the same endpoint, and they look identical once the raw body is gone.

Last thing: run a subscription audit on a schedule. List what each Meta app is actually subscribed to (messages, message_template_status_update, whatever your code assumes) and diff it against what you handle. Subscriptions silently vanish when an app gets re-authed. The bug is invisible until the day a whole channel goes quiet, and then you'll spend hours checking every other layer first. I did.

The shape of it

Every defense above is the same idea wearing five hats. The webhook is a stream of claims, not facts. Dedupe the claims. Filter the echoes out. Accept the unverifiable ones quietly. And before you act on any of them, re-read the world's actual state.

Meta's delivery model is at-least-once, along every dimension - messages, statuses, retries, regions. The only safe architecture assumes every callback arrives zero, one, or several times, and that all three cases are normal.

I build Conversify, an AI receptionist that lives in front of these webhooks full time - answering, booking and selling over WhatsApp, Instagram, Messenger, email and web chat for small service businesses. Self-serve, 14-day free trial, and it tells people it's AI.

Next in the series, the calendar half of the story continued: availability search that survives multi-staff, blocked times, and the customer whose phone is in another timezone. Part one is here.

How an AI receptionist actually books an appointment over WhatsApp (calendar sync, freeBusy, and why "no" should never be the final answer)

David Friedman — Sun, 30 Aug 2026 17:42:39 +0000

How an AI receptionist actually books an appointment over WhatsApp (calendar sync, freeBusy, and why "no" should never be the final answer)

A technical walkthrough of the booking pipeline. Plus a detour through behavioral science, because the hard part of scheduling was never the calendar.

Rory Sutherland has a line that runs my product

The Ogilvy vice chairman has spent twenty years making the same argument: most product problems aren't engineering problems. They're psycho-logic problems. People don't experience your infrastructure. They experience the interaction.

His favorite example is the train operator that put a schedule on the platform. Waits didn't get shorter. They just stopped feeling infinite. The problem was never the waiting. It was the not knowing.

Booking a haircut is exactly this. The customer's actual complaint isn't "you lack scheduling software." It's the interaction cost. Interrupt you, or wait, or call and hope. Every option is socially expensive for a haircut.

And on the other side of the counter: the owner's complaint is that 11pm customers message, hear nothing, and quietly book the salon down the street instead.

Both sides want the same thing. The transaction, minus the negotiation. That reframe is the product. Everything below is engineering in service of killing the negotiation.

What "just connect a calendar" turns out to mean

Here's the message that ends in a real booking:

"Hi! Do you have anything Saturday afternoon for a balayage?"

Five lines. To answer honestly - not "probably!", not "let me check and get back to you", but a slot that will survive contact with reality - the AI needs all of this:

Who can perform it. A multi-staff salon isn't one calendar. It's N calendars, and not everyone does balayage.
What's free. Existing bookings plus every external event on each staff member's personal Google Calendar. The dentist. The school run. Everything.
What the business allows. Opening hours, blocked times, per-staff daily booking caps, and whether the slot is even long enough for the service plus buffer.
Where the customer is. A Madrid salon with a Miami WhatsApp number needs two different "3pm"s.
An answer in seconds. Because response time is the signal. A reply that lands while the customer is still holding the phone says "this business is alive." A perfect answer two hours later says "this will be a project."

That last point is why the AI lives in the message path, wired to the calendar, and not behind a "click here to book" link. The moment the customer has to open a second app, you've rebuilt the negotiation you were hired to remove.

This is the core promise of Conversify: calendar-wired answers in seconds, not "we'll get back to you."

The availability pipeline

Every booking-capable message runs through roughly this:

message → intent + service + preference(s)
        → candidate staff (skills, active status)
        → for each candidate:
             working hours ∩ unblocked time
             − calendar events (local + Google freeBusy)
             − per-day booking cap for that staff member
             − service duration + buffer
        → ranked slots (earliest match wins, preferences win)
        → offer 1-3 concrete options → customer picks → book

The part developers underestimate is always freeBusy. Here's the mistake I made first: caching calendars. Feels sensible. It isn't. Staff edit their calendars from their phones in the checkout line, and your cache is one edit behind, always. The fix is dumb - query freeBusy live for every candidate slot - and it wiped out the entire class of "I double-booked a haircut against my dentist appointment" complaints. Cost is an API call per candidate. Fine. Buy the API calls.

Blocked times are the quiet hero of the whole design. An owner drops "closed 2-3pm daily" as a blocked range and it applies everywhere - the AI conversation, the public booking page, the manual booking screen. One source of truth. I cannot stress this enough: if the bot, the booking page, and the staff each have their own idea of availability, you will ship a bot that cheerfully sells appointments during the owner's kid's birthday party. Ask me how I know.

Timezones you solve boringly and correctly. Store absolute times. Display the customer's local zone. "Saturday at 4pm" must read back to the customer as their 4pm. Sounds obvious. The first bug report where it isn't will burn a day of your life.

Confirmation, reminders, and the "no" that becomes a "yes"

Booking isn't the finish line. WhatsApp bookings have a specific failure mode: the customer says yes in chat, then never shows, because the appointment lives in a chat bubble that has scrolled away under a week of family group messages.

So the loop closes in three beats.

Instant confirmation. A proper WhatsApp template message - the utility-category kind, pre-approved so it can arrive outside the 24-hour service window - with date, time, staff name, and location.

A confirmation request the customer can literally answer "YES" or "NO". This isn't bureaucracy. It's a super-stimulus of reliability. The business is visibly keeping its act together.

A reminder before the appointment. And if it's cancelled, the slot returns to the pool immediately, and waitlisted requests for that exact window get first refusal.

That last part is where Sutherland earns his keep. In psycho-logic terms, a "no" is not an outcome. It's a failure of imagination.

The naive system hits Saturday-is-full and says "sorry, we're fully booked." Conversation dies. The customer's mood flips from "I want this salon" to "I want this to be over," and they call whoever answers next.

The right system treats full-ness as a reframe. Offer the nearest alternative. Offer the same stylist on a different day. Capture the request against the waitlist for cancelled slots. The customer now experiences a business fighting to fit them in, which is the entire signal an appointment was supposed to deliver in the first place. Same calendar. Same slots. Different problem. That is the trick Sutherland keeps pointing at, and most scheduling software has never heard of it.

Same discipline for escalation: if a human has stepped into the thread, the AI stands down before booking anything. It re-checks with every reply, mid-conversation. An AI that books over a human's active conversation signals chaos, and chaos is the one signal you can't afford.

The stack this runs on

Next.js and Firebase App Hosting. The WhatsApp Business API for templates and webhooks. Genkit on Google's Gemini for the understanding layer. Firestore for state. Google Calendar APIs for the truth about time.

One rule above all of it: the calendar is the source of truth, and the AI is a very polite client of it. It never invents availability. It only resolves it.

That sentence is most of the product, honestly. A receptionist that hallucinates Saturday openings is worse than no receptionist, because it converts a missed message into a broken promise with a witness.

If this is your problem too

I build Conversify - an AI receptionist that answers, books and sells over WhatsApp, Instagram, Messenger, email and web chat, for people who have a business to run more than an inbox to administer. Self-serve. Minutes to set up, not months. 14-day free trial. And it always tells the person it's AI.

Next post in this series, if it survives the fix list: handling WhatsApp Cloud API webhooks without deduplicating yourself into despair.

Event-Driven Architecture with WebSockets

David Friedman — Thu, 14 May 2026 15:57:36 +0000

Event-Driven Architecture with WebSockets

Real-time communication patterns for modern web apps.

AppBrewers — real-time development Malta.

Database Sharding Strategies for SaaS

David Friedman — Thu, 14 May 2026 15:56:43 +0000

Database Sharding Strategies for SaaS

Horizontal scaling patterns for multi-tenant applications.

AppBrewers — SaaS backend specialists Malta.

Edge Computing with Cloudflare Workers

David Friedman — Thu, 14 May 2026 15:41:42 +0000

Edge Computing with Cloudflare Workers

Run code at the edge for sub-50ms response times.

AppBrewers — edge computing specialists Malta.

AI Agent Architecture Patterns 2026

David Friedman — Thu, 14 May 2026 15:41:25 +0000

AI Agent Architecture Patterns 2026

ReAct, Plan-and-Execute, and Multi-Agent patterns explained.

AppBrewers — AI development agency Malta.

AI Receptionist vs Human Receptionist

David Friedman — Thu, 14 May 2026 15:02:39 +0000

AI Receptionist vs Human Receptionist\n\nComparing costs, availability, and customer experience.\n\nAppBrewers builds AI receptionists for businesses.

Mobile App Development Trends 2026

David Friedman — Thu, 14 May 2026 14:54:22 +0000

Mobile App Development Trends 2026

Key trends shaping the mobile industry this year.

Learn more at AppBrewers.

Web Development Best Practices 2026

David Friedman — Thu, 14 May 2026 14:54:02 +0000

Web Development Best Practices 2026

Tips for building modern web apps.

Progressive Web Apps vs Native Apps: Which Should You Build in 2026?

David Friedman — Thu, 14 May 2026 14:42:18 +0000

PWAs have come a long way. Here is when they beat native apps — and when they do not.

By David Friedman, Founder of AppBrewers

Progressive Web Apps (PWAs) promise native-like experience without app store submission. But they are not a universal replacement. We have built both. Here is the honest comparison.

What Is a PWA?

A PWA is a web app that uses service workers, manifests, and modern APIs to provide:

Offline functionality
Push notifications
Home screen installation
Background sync

PWA Advantages

Advantage	Detail
No app store gatekeeping	Update instantly, no review process
Lower development cost	One codebase for all platforms
SEO discoverable	Indexed by Google, found organically
No installation friction	Visit URL, add to home screen
Smaller download size	Kilobytes vs megabytes

Native App Advantages

Advantage	Detail
Full hardware access	Bluetooth, NFC, ARKit, sensors
App store distribution	Trust signal, organic discovery
Background processing	Location tracking, audio playback
Better performance	Compiled code, not JavaScript
Push notification reliability	iOS APNS is more reliable than web push

Decision Matrix

Requirement	Choose PWA	Choose Native
Offline-first	Yes	Yes
Push notifications	Yes (Android)	Yes (iOS + Android)
Camera/Bluetooth/AR	No	Yes
Budget under 10k	Yes	Maybe
App store presence	No	Yes
Rapid iteration	Yes	No

Our Recommendation

Build a PWA if: Your app is content-focused, has simple interactions, or needs fast deployment.

Build native if: You need hardware access, complex animations, or app store distribution is critical.

Build both if: Budget allows. PWA for reach, native for power users.

PWA Tech Stack

Layer	Technology
Framework	Next.js 15 / Nuxt 3
Service Worker	Workbox
State	Zustand / Pinia
Backend	Firebase / Supabase
Hosting	Vercel / Firebase Hosting

Need a PWA or Native App Built?

We build PWAs and native apps for startups. React Native, Flutter, or Next.js PWA. 6-10 weeks. Fixed pricing. Malta-based.

Originally published on the AppBrewers Blog.

No-Code vs Custom Development: When to Switch

David Friedman — Thu, 14 May 2026 14:37:07 +0000

No-code tools get you to MVP fast. But there is a point where they become a liability. Here is how to know when to switch.

By David Friedman, Founder of AppBrewers

We have rescued 8 products from no-code platforms that could not scale. We have also advised founders to stay on no-code longer than they planned. Here is the framework.

The No-Code Sweet Spot

No-code is perfect for:

Validating ideas with real users
Internal tools and dashboards
Simple marketplaces and directories
Landing pages and marketing sites
MVPs with standard features

When No-Code Breaks

Limitation	Symptom	Solution
Performance	Page load >3 seconds	Custom backend
Custom logic	Workarounds everywhere	Custom code
Scale	100+ concurrent users	Optimized architecture
Integration	Missing API connectors	Custom integrations
Cost	500+ Euro/month for simple app	Self-hosted

Platform Comparison

Platform	Best For	Switch Point
Bubble	Complex web apps	1,000+ users
Webflow	Marketing sites	Ecommerce at scale
Airtable	Internal tools	External users
Zapier	Automation	100+ zaps
Adalo	Simple mobile apps	Custom features

The Hybrid Approach

Many successful startups use no-code for the frontend and custom code for the backend.

Example:

Frontend: Webflow
Backend: Firebase Functions + Firestore
Auth: Firebase Auth
Payments: Stripe

This gives you speed and scalability.

Migration Strategy

Phase	Action	Timeline
1	Audit no-code limitations	1 week
2	Design custom architecture	2 weeks
3	Build core features	4-8 weeks
4	Migrate data	1-2 weeks
5	Parallel run + switch	1 week
6	Decommission no-code	Immediate

Cost of Switching

Factor	Cost
Custom development	15,000-50,000 Euro
Data migration	2,000-5,000 Euro
Downtime risk	Revenue dependent
Team retraining	1-2 weeks

Need Help Migrating from No-Code?

We migrate products from Bubble, Webflow, and Adalo to custom Next.js and React Native. No data loss. Zero downtime. 6-10 weeks.

Originally published on the AppBrewers Blog.

Web App Security Checklist 2026: Protect Your Startup from Day One

David Friedman — Thu, 14 May 2026 14:35:56 +0000

Security is not a feature you add later. It is a foundation you build from day one. Here is our production checklist.

By David Friedman, Founder of AppBrewers

We have audited 20+ web apps for security. The same vulnerabilities appear repeatedly. Here is the checklist we use for every project.

Authentication

[ ] Use OAuth 2.0 / OpenID Connect (Firebase Auth, Clerk, Auth0)
[ ] Enforce strong passwords (8+ chars, complexity requirements)
[ ] Implement brute-force protection (rate limiting)
[ ] Use secure session tokens (HTTPOnly, SameSite, Secure flags)
[ ] Add multi-factor authentication for admin roles

Authorization

[ ] Verify permissions on every API endpoint (server-side)
[ ] Use Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC)
[ ] Never trust client-side permission checks
[ ] Validate resource ownership (user A cannot access user B's data)

Data Protection

[ ] Encrypt data at rest (AES-256)
[ ] Encrypt data in transit (TLS 1.3 minimum)
[ ] Hash passwords with bcrypt / Argon2 (never MD5 or SHA1)
[ ] Mask sensitive data in logs
[ ] Implement GDPR-compliant data deletion

Input Validation

[ ] Validate all inputs server-side (never trust client)
[ ] Sanitize HTML to prevent XSS
[ ] Use parameterized queries (prevent SQL injection)
[ ] Validate file uploads (type, size, content scan)
[ ] Set strict Content Security Policy headers

Infrastructure

[ ] Use HTTPS everywhere (HSTS enabled)
[ ] Keep dependencies updated (automated scanning)
[ ] Implement DDoS protection (Cloudflare, AWS Shield)
[ ] Enable Web Application Firewall (WAF)
[ ] Regular security audits and penetration testing

Monitoring

[ ] Log all authentication attempts
[ ] Alert on suspicious activity (impossible travel, brute force)
[ ] Monitor for dependency vulnerabilities (Snyk, Dependabot)
[ ] Incident response plan documented

Common Vulnerabilities We Fix

Vulnerability	Impact	Fix
XSS	Session hijacking	CSP + input sanitization
CSRF	Unauthorized actions	SameSite cookies + tokens
SQL Injection	Database access	Parameterized queries
IDOR	Data leakage	Server-side authorization
Insecure Direct Object Reference	Account takeover	UUIDs + permission checks

Need a Security Audit?

We build secure web apps from the ground up. Auth, encryption, compliance. Penetration testing available. Malta-based security team.

Originally published on the AppBrewers Blog.