Correctness and consent
A replayed webhook and a duplicate send are defects, not the integrator's problem.
Webhook signing answers whether a message claiming to come from a channel actually did. Idempotency answers whether the same instruction arriving twice does the thing once. Together they decide whether a booking or a payment can be replayed safely.
One vendor in the set documents both. One documents neither and says so in its own pages: it promises no signing and explicitly disclaims idempotency. The one that gets both right is a lifetime-deal product from Faridabad, ahead of every enterprise messaging platform in the study.
- 1 of 13
- WhatsApp platform vendors torn down that document both webhook signing and idempotency. Wati is the vendor that documents neither. Torn down 14 November 2026.
Delivery truth
Accepted is not delivered, and the interface never blurs them.
A channel accepting a message is a receipt from the channel. A person receiving it is a different event, at a different time, and sometimes it never happens. A console that says "sent" while the ledger says "accepted" has told the owner something about their customer that is not true.
So the state vocabulary is one vocabulary everywhere, and the word is always present beside the colour: requested, pending, accepted, delivered, read, failed, unknown. A reminder that was accepted and never delivered is visibly not delivered.
The attempt ledger
Keyed per business, per booking, per workflow and per offset, so a retry cannot double-send. A reconnect never presents a person with a decision they already made.
No number in a log
Status is correlated by salted hash, so a customer's telephone number does not sit in an operational log in order for delivery state to be known.
A trigger, not a dashboard
Failure rate, delivery rate, duplicate send and webhook anomaly each carry a kill trigger. The remedy for a misbehaving sender is that it stops, not that someone notices a chart.
Consent
A customer who says stop is stopped everywhere at once.
One suppression register, read by every sender before it sends, across WhatsApp, Messenger, Instagram, Telegram and email. Not one register per assistant and not one per workflow, because the customer cannot see which assistant they were talking to and should never have to say it twice to the same business.
Consent is recorded before anything proactive is sent, and it belongs to the person rather than to the product. Switching an assistant off is a separate act from suppressing a sender, and it must never cancel a consent instruction: silencing the assistant is ours to do, and withdrawing consent was never ours to undo.
What it cannot say
An assistant cannot state a fact nobody approved.
An independent auditor reads every outbound message against the facts the business actually approved, and blocks the rest. That covers a price, a capability, a discount, a product the business does not carry, and a promise that a person will make contact.
Where a message does promise a human, a human is notified at send time. The promise and the notification are one act, because a promise nobody heard is worse than silence, and the customer who was told someone would call is the person least able to check whether anyone was told.
Alongside it: a refusal gate graded by what was asked, a deterministic pass over register and typography that no model is trusted to obey, and a kill switch per assistant that is read every turn, so switching one off takes seconds and no deployment.
The gate the auditor cannot be
An output audit compares a message against the facts it was given, so a brief that was itself invented passes cleanly. The brief is therefore audited before a word is written, by a separate gate, against the approved facts.
Fail closed
A guard that cannot read refuses. A verdict that cannot be parsed is a block, not a pass. A read that cannot tell absent from failed is never written back.
Blind spots, written down
Every control states which direction it fails.
An allowlist cannot refuse one specific named thing: a guest list cannot express a restraining order. A denylist cannot require completeness: it fails on the term nobody thought of. Both are correct tools, each is blind in exactly one direction, and the failure is never the choice. The failure is not knowing which one you are holding.
So each gate records, in the file beside it, what it permits or refuses and which of those it cannot express. A control carried from one risk to an inverted one does not fail loudly. It passes. That is the whole reason the sentence has to be written down before anyone reuses the control.
The same rule governs the automated accessibility and weight checks on this site, and it is why their clean runs are reported here as evidence of the absence of what they test for, and of nothing else.
Takeover
One switch, per thread, and it is reversible.
A person can take any conversation over at any moment, and the assistant stands down for that thread until it is handed back. The person taking over sees the last turns verbatim with the author of each one, what the assistant was about to do, and the facts it was working from. Every outbound turn carries a resolvable author, so nobody has to guess what was said in their name.
Rollout is by gate rather than by launch: off, dry, canary, live, killed. A business is switched on one workflow at a time and switched back in one move.