The 24-hour window: the rule that breaks most first integrations

Almost every WhatsApp integration hits the same wall in its first week, and almost every team diagnoses it wrong.

The symptom: messages sent during development go through perfectly. Messages sent from production, days later, are rejected. Nothing in the code changed.

WhatsApp distinguishes between a conversation a customer started and one a business started. When a customer messages you, a window opens during which you may reply freely — any content, no approval. That window lasts 24 hours from their most recent message.

Outside it, free-form messages are not delayed or queued. They are refused. The only thing that goes through is a template approved in advance.

In development you were inside the window, because you had just messaged yourself from a test handset. In production you were not.

The rule is not complicated. What makes it break integrations is that it is a state machine and most send code treats it as a configuration flag.

It is worth understanding rather than resenting. The window exists because the alternative — letting any business with your number start a conversation whenever it likes — is the thing that ruined SMS as a channel.

The template approval step is the price of a channel where users still read the messages. Treat it as a feature of the medium rather than an obstacle in it, and the design decisions get easier.

• Model the window explicitly. Store the timestamp of the last inbound message per contact. Your send path should know, before it calls anything, which kind of message is permitted.
• Have templates ready before you need them. Approval is not instant. A support process that discovers at 2am that it needs a template it has not filed is a support process that does not reply until morning.
• Do not use a template where a reply would do. Templates are billed by category; replies inside the window are the cheap path and the more natural one.

Every messaging channel has a rule of this shape — an asymmetry between conversations the customer started and conversations you started. WhatsApp's is the most visible because it is enforced by an API that says no. Email's version is enforced by a spam classifier that says nothing at all, which is worse.

It is worth being precise, because teams routinely model this wrong.

The clock starts at the customer's most recent inbound message, not at the start of the conversation. Every new message from them resets it. It is per contact, not per agent, per ticket or per session — so a customer who writes to sales and is transferred to support has one window, not two, and both teams are spending it.

That last point has an operational consequence people discover the hard way: a conversation sitting in a queue is burning the window. If your support target is "reply within four hours" and the window is twenty-four, you have more headroom than you think — until a public holiday, at which point a queue of open conversations silently converts into a queue of template sends.

Three patterns that work:

Surface the clock to the agent. An inbox that shows how long is left on each conversation lets a human make the right call about what to pick up next. One that does not turns an avoidable cost into a surprise.

Make the last message an invitation. If a conversation is ending but a follow-up is likely, closing with a question keeps the door open, because their reply restarts the clock. This is not a trick — it is the medium working the way it was designed to.

Batch the expiring. If several conversations are about to close and each needs a follow-up, that is a scheduled job, not a discovery at the moment of sending.

Because free-form replies inside the window are the cheap path, the economics reward being responsive rather than being efficient. A team that answers in ten minutes spends less per resolved conversation than one that answers in ten hours, even before you count the difference in customer satisfaction.

That is an unusual alignment and worth exploiting deliberately. Most channels punish responsiveness with cost. This one rewards it.

• The window starts at their last message and resets on every one.
• It is per contact. Queue time spends it.
• Outside it, free-form is refused rather than queued — have templates approved in advance.
• Responsiveness is cheaper here, not more expensive. Design the operation accordingly.

Three specific mistakes, and all three come from the same root: treating a conversation state as a property of the contact.

Storing "can message" on the contact record. It is true for a conversation and for a period, not for a person. A flag written at import time is wrong within a day.

Checking the window at queue time rather than send time. A message queued at hour twenty-three and sent at hour twenty-five is rejected. The check has to happen at the last possible moment.

Assuming a template can substitute for a reply. It can, and it changes the economics and the tone. A support answer delivered as an approved marketing-shaped template reads exactly as badly as it sounds.

Model the conversation. It has an id, a last-inbound timestamp, and a derived state. The send path reads that state and picks free-form or template accordingly — and it logs which one it used, because the billing question arrives later and the answer has to be retrievable.

That is perhaps thirty lines of code, and it is the difference between a channel that works and one that fails unpredictably at the twenty-fifth hour.