What is the WhatsApp 24-hour window? Queues change the answer

WhatsApp 24-hour window

Under current WhatsApp Business Platform policy, a business may reply to a user message without a template when the reply is within 24 hours of the user’s last message. Outside that window, the business can contact the user only through an approved message template, subject to permission and policy requirements. The window is best understood as a moving state machine, not a one-time conversation flag.

Inside versus outside the window

Inside the window

The business can send service replies without using an approved template. Automation is allowed, but Meta policy requires clear, prompt escalation paths when automation is used for customer service.

This is where a support bot can answer questions, an agent can troubleshoot an order, or the business can continue a customer-initiated conversation.

Outside the window

The business must use an approved message template to re-initiate or continue contact. The template must be used for its designated purpose and remains subject to Meta review and status/quality controls.

Current WhatsApp pricing also treats service messages as a distinct category and describes the 24-hour window as the service window. Pricing details can change independently from the window rule, so the durable operational logic should not hard-code a price assumption into eligibility.

Keep the latest user-message time as source data

The conversation record can include:

• WhatsApp user identifier/phone number
• business account/phone number identity
• latest inbound user-message timestamp
• computed window expiry
• inbound message/event ID
• current opt-in and opt-out state by purpose
• active workflow jobs waiting to send
• candidate template and category if an out-of-window fallback is allowed

The expiry can be cached for convenience, but derive it from the latest valid user event. A new inbound message must update the state atomically enough that workers do not continue using an old expiry.

What happens when a user replies to a template

Imagine a business sends an approved order-update template while no customer service window is active. The user replies, “Can I change the delivery date?”

That inbound user message opens a new 24-hour customer service window. The bot or support agent can now continue the customer-service conversation using non-template replies during the active window. This is why template delivery and service-window state interact but remain different concepts.

Multi-worker and delayed-webhook edge cases

At scale, inbound webhooks and outbound workers can race one another. A platform should make decisions against a canonical conversation state, not whichever event a worker happened to see first. Useful safeguards include idempotent inbound processing, monotonic tracking of the latest user-message time, and a final eligibility check before provider submission.

If event ordering is uncertain, prefer a conservative result rather than sending a message that assumes the window is open.

Do not schedule from a cached “window open” boolean

A boolean such as conversation_open=true becomes stale immediately unless every inbound event and clock transition updates it perfectly. Prefer storing last_user_message_at as the source fact and deriving window_expires_at from that value. At send time: > window_open = now < last_user_message_at + 24 hours Then apply the platform’s current semantics. This makes the decision reproducible and resilient to worker restarts.

Multiple inbound messages should move the expiry forward monotonically

Webhook delivery can be out of order. If the system receives a delayed event for an older user message after a newer one, it must not move last_user_message_at backward.

Update the state only when the inbound event timestamp is newer than the stored latest-user-message timestamp, while separately retaining all messages in conversation history. This avoids accidentally expiring a window early.

Queue behavior outside the window should be explicit

When a delayed job crosses expiry, the workflow needs a declared policy rather than an implicit provider error. Possible policies:

• convert to template: use a pre-approved template that matches the original purpose
• skip: if a template would be awkward or permission is absent
• wait for user: stop automation and resume only after a new inbound message
• handoff: alert a human agent that the free-form response can no longer be sent

Record which path was chosen so support can explain why the message changed format or did not send.

Window state is per user-business conversation

Do not accidentally share an active window across unrelated WhatsApp business numbers or brands in a multi-tenant platform. The user’s message opens the service context with the business identity/account that received it, not with every merchant using your infrastructure.

Store both conversation time and provider event time

Distributed systems can receive webhooks late. Preserve the provider’s event timestamp and the ingestion timestamp separately. Use the authoritative conversation event time, with ordering safeguards, to derive the latest customer-message state.

That distinction makes incidents debuggable: “the customer replied at 10:03, but our webhook arrived at 10:07 after a 10:05 send” is a very different failure from “the customer replied only after the send.”

What does this page teach beyond a generic glossary definition?

It teaches the WhatsApp window as a send-time state machine. User messages open/reset it; business messages do not keep it alive by themselves; and queued jobs must recheck the latest inbound timestamp before deciding whether they can send a free-form service reply or need an approved template.

Worked example

Automation creates a subtle race.

• Suppose an agent receives a user message at 9:00 a.m. and schedules a follow-up for 8:30 a.m. the next day. At scheduling time the follow-up is 23.5 hours away, so it appears to be inside the window

• But a worker backlog delays execution until 9:10 a.m. The message is now outside the 24-hour window

The send system should re-evaluate the window against the latest user-message timestamp immediately before submission. It can then:

• send the free-form/service response if the window is still active
• switch to an eligible approved template if product logic allows
• or skip/defer the message if no compliant template and permission state exists

Do not rely on the eligibility result computed when the workflow step was first scheduled.

What WhatsApp 24-hour window requires

A practical WhatsApp 24-hour window rollout

One step.

1. 01
   The critical boundary is send time, not workflow start timeConsider a support automation triggered at 14:15, when the latest customer message was at 14:20 the previous day. The workflow waits 10 minutes for an inventory lookup and attempts to send at 14:25. The 24-hour service window has now expired. The correct decision is based on 14:25 state. The fact that the workflow started while the window was open does not freeze eligibility for a later free-form message. The worker must switch to an approved template when appropriate or take the workflow’s declared skip/handoff path. The same principle applies in reverse. A template job may be queued while the window is closed, then the customer sends a new message before dispatch. The system can re-evaluate current state rather than blindly following an old snapshot, while still respecting the intended category and permission.

What passes and what does not

• A window tells you which message form may be used at that moment. It does not answer every consent question
• If a user contacts a furniture store to ask about delivery, that conversation may open the service window. The business should not infer that the user has enrolled in ongoing promotional broadcasts after the conversation ends
• Conversely, a user can have valid permission for marketing messages while the service window is closed. The business may still be able to send an approved marketing template, subject to current policy, consent and other eligibility rules
• Keep these states separate:
• permission/opt-in state
• 24-hour service-window state
• template approval/category state
• opt-out/block state