What WhatsApp cannot do here
Two things are not proven in production and this page says so first. No WhatsApp number is connected in production, so no outbound message has ever gone to Meta from the live build; and the QR route cannot open Meta's signup there. Inbound, the signature check, automation and approval are proven live against a probe number.
Two things that are not proven in production#
No WhatsApp number is connected in production. Nothing outbound has reached Meta from the live build. A real send, and the delivery and read statuses that follow it, are proven only against a stubbed Meta in the test_whatsapp_platform_v1 suite. Everything on the sending side of these pages — the window rule, the template refusal, the category decision, the hourly cap, the metering — describes code that has been exercised against a stub and not against Meta itself.
The QR route cannot open Meta's signup in production. The mandatory warning, the word-for-word consent and the audit record all work; the button after them reports that QR linking is not switched on. Meta allows coexistence only for a Tech Provider or Solution Partner app with Embedded Signup, and that application has not been made. A workspace can therefore accept the QR warning today and still not link a number.
What *is* proven live, on a probe number: a signed webhook to the public URL was stored, drafted by the real model and held for approval; a forged webhook was refused 403; and the probe rows were then removed. Inbound, the signature check, the automation decision and the approval queue are the parts of this channel with production evidence behind them.
What Meta decides, not Connect#
| Area | Meta's rule | How it shows up |
|---|---|---|
| Message templates | Which templates exist, which are approved, and what category each carries | An unapproved name, or a name not on the synced list, is refused before the send |
| The 24-hour window | A business may write freely only for 24 hours after the person's own message | A refusal with the window reason, on a message every other rule allowed |
| The billed category | Service, utility, marketing or authentication — Meta's classification, not the sender's | The category on a status, and the number the usage view prices against |
| Throughput | How fast a number may send before Meta says slow down | A rate-limit code, reported as a rate limit rather than as a broken message |
| Coexistence | Whether a QR-linked number is allowed at all, and for which app | The QR button, reporting that linking is not switched on |
Connect does not normalise any of that into a comforting fiction. Where Meta refuses, the refusal and its reason are what you see; where Meta reports nothing, nothing is shown. The alternative — inventing a status or a template that was never approved — surfaces in front of a customer, which is the worst place for it.
What Connect does not do on this channel#
- It does not create or operate your WhatsApp Business account, obtain a number, or submit templates for approval.
- It does not extend, reopen or work around the 24-hour window.
- It does not fabricate a delivery or read status where Meta reported none.
- It does not run a scraped WhatsApp Web session, device emulation, or anything else meant to get around Meta's controls. The QR route is Meta's own coexistence flow and nothing else.
- It does not generate media. Where a reply needs a document, the file comes from the workspace's own files, and nothing above 16 MB is uploaded.
- It does not run WhatsApp groups or broadcast lists as a channel.
- It does not treat a WhatsApp profile name, or a QR-linked handset's address book, as an identifier — matching is by number.
None of these is a defect being worked around. Each is a boundary between what an application controls and what a messaging platform controls, and knowing where the boundary sits saves the hour otherwise spent looking for a setting that cannot exist.
Limits that are Connect's own#
- Reply length and style
- Governed by your standing instructions, not by a hard cap. A chat reply that reads like an email is a configuration problem, and the channel tier is where to fix it.
- What Connect knows
- Bounded on purpose. Knowledge and memory contribute fixed budgets to a reply, so a fact that must always apply belongs in Memory rather than deep in a transcript.
- The plan's allowance
- On a customer workspace, outbound messages are metered by category rather than counted. A spent allowance holds a send rather than losing it. The Owner workspace has no plan.
- The hourly automatic-send cap
- 120 per number per hour on an Official API number, 20 on a QR-linked one. This is Connect's cap, chosen because a coexistence number is also somebody's phone. Over it, sends wait for the next hour.
- One number per workspace
- A workspace resolves to one WhatsApp account. Connecting a second number replaces the first, and a number already connected elsewhere on the deployment is refused.
- Autonomy
- A reply is only sent if the narrowest applicable rule says so.
offanddraft_onlyboth produce a silent channel, for different reasons.
Planning around the window#
Most of the friction on this channel traces back to one rule: a business may write freely only inside a window the person opened, and otherwise only with an approved template. Three habits make that survivable.
Answer promptly while the window is open.
Result Most conversations complete inside it and never meet the limit at all.
Put dated commitments on a channel that has no such rule when the date is far out.
Result Follow-ups on WhatsApp sets out when
emailorphoneis the more reliable promise.Sync templates from Meta and nominate a follow-up template before you need one.
Result The synced list decides what is possible when a window has closed. A name Meta has not approved is refused, and approval is a slow answer if it is asked for in the moment.
Questions#
Is WhatsApp less capable in Connect than email?
It is differently constrained. Everything the engine does — grounding, memory, autonomy, follow-ups, the relationship record — works identically. What differs is that the platform, not Connect, decides when a business may write.
Can Connect send images and documents on WhatsApp?
Yes in code: media is uploaded to Meta and then sent by id, up to 16 MB, for images, documents, audio and video. Like every other outbound path it is proven against a stubbed Meta rather than against a connected number.
Is the QR-linked route a way around Meta's rules?
No — it is Meta's own coexistence flow through Embedded Signup, and Connect contains no WhatsApp Web automation or device emulation of any kind. It is also not usable in production: the warning and consent work, and the signup step reports that QR linking is not switched on.