WhatsApp's 24-hour customer service window, explained for developers

The WhatsApp 24-hour rule is one of the most important constraints in the WhatsApp Business Platform.

It controls when a business can send free-form messages and when it must use approved templates. If you build WhatsApp support tools, AI agents, automations, broadcasts, or CRM workflows, your system needs to model this rule explicitly.

TL;DR

• When a user messages your business, WhatsApp opens a customer service window.
• The window lasts 24 hours from the user’s latest message.
• Inside the window, you can send free-form replies.
• Outside the window, you need an approved message template.
• Non-template automation, AI agent replies, and human handoff responses must respect the window.
• Templates can reopen a conversation, but they must be approved and categorized correctly.
• Groups API has a different service-window behavior, but it is only relevant if you are eligible to use Groups API.

What the 24-hour rule means

The rule is simple:

A user message opens or refreshes a 24-hour customer service window between that user and your business.

Inside that window, your business can send normal session-style responses. Outside that window, WhatsApp restricts business-initiated messaging. You usually need to send a pre-approved template instead of arbitrary text.

For product design, the window is not just a policy detail. It determines whether a send button, automation step, webhook reply, or agent response is allowed to work.

Inside the window

Inside an open service window, you can send free-form messages such as:

• support replies
• AI agent responses
• human handoff messages
• follow-up questions
• media messages
• interactive messages, when supported by the product path you are using

This is the natural mode for support and conversational automation. A customer asks a question; your system replies.

Outside the window

Outside the service window, you cannot rely on free-form messages. You need an approved template message for most business-initiated sends.

Common examples:

• appointment reminders
• order updates
• payment reminders
• marketing campaigns
• re-engagement after a support conversation has gone quiet
• authentication or verification flows

This is where many broken integrations come from. The code path works during testing because the tester recently messaged the business. Then it fails in production because the real recipient has no open service window.

Why developers should model the window

If your app sends WhatsApp messages, the 24-hour window should be represented somewhere in the product.

At minimum, you want to know:

• when the last inbound user message arrived
• whether the current conversation is inside the service window
• whether the planned outbound message is a template or non-template
• which fallback template to use if the window is closed
• whether the send should be blocked, retried, or converted to a template flow

Without that state, the integration becomes unpredictable.

How this affects AI agents

AI agents are especially easy to get wrong.

An agent may be able to draft a perfect reply, but WhatsApp may still reject the send if the conversation is outside the service window and the reply is not a template.

For WhatsApp agents, the system should distinguish between:

• reply mode, when a user has recently messaged and free-form output is allowed
• template mode, when the agent or workflow needs to send an approved template
• handoff mode, when a human needs to respond inside the same policy constraints

The agent should not be the policy engine. The WhatsApp messaging layer should enforce whether the message type is allowed.

How this affects human handoff

Human agents have the same constraint.

If a customer wrote in recently, a support rep can answer normally. If the conversation has been inactive for more than 24 hours, the rep may need to use a template to restart the conversation.

Good inbox software should make this clear. It should not let a human compose a long free-form reply and only discover after sending that WhatsApp rejected it.

Templates are not just fallback text

Templates are pre-approved messages. They have categories, review status, language, parameters, and sometimes strict content expectations.

A developer-friendly WhatsApp implementation should track:

• template name
• language
• category
• approval status
• parameter schema
• connected number or account where the template exists
• when the template was last synced

Do not treat templates as ordinary strings in a config file.

Category matters

Template category affects pricing and delivery behavior. Meta can also reclassify templates.

Common high-level categories include:

• utility
• marketing
• authentication

The exact behavior depends on Meta’s current pricing and policy model, but the engineering principle is stable: store category, show category, and do not assume an approved template will behave like every other approved template.

Practical implementation pattern

A simple policy gate can protect most systems:

if message_is_template:
  send_template
else if conversation_has_open_service_window:
  send_free_form_message
else:
  block_or_prompt_for_template

The real system will have more detail, but this is the core decision.

In Kapso, non-template sends are expected to have a recent conversation window. If the conversation is outside the window, the correct next action is to send a WhatsApp template to reopen the session.

What to show users

If your product has an inbox, automation builder, or agent UI, expose the rule in the workflow without overwhelming people.

Useful UI states:

• open service window
• window expires at
• template required
• selected template is approved
• selected template is unavailable on this number/account
• send blocked because the service window is closed

Avoid burying this in logs. The user needs to know before they click send.

Groups API caveat

Groups API has different service-window behavior.

For groups, when any user in the group messages the business, Meta says a customer service window opens or refreshes between the business and the entire group. During that window, certain group messages can be free.

This is not the normal 1:1 rule. But it only matters if your business is eligible for Groups API, which currently requires an Official Business Account. Most businesses should not design around group behavior unless they know they have access.

Common mistakes

Testing only with fresh inbound messages

If your test phone just messaged the business, the service window is open. That can hide failures that appear later in production.

Test both cases:

• user messaged recently
• user has not messaged in more than 24 hours

Sending agent replies outside the window

Do not let an LLM decide whether WhatsApp policy allows a send. The messaging layer should enforce the rule.

Treating templates as optional

Templates are required infrastructure for business-initiated WhatsApp messaging. If your product needs reminders, broadcasts, reactivation, or delayed follow-up, you need templates.

Not storing the last inbound timestamp

Without the last inbound timestamp, you cannot reliably know whether a free-form message is allowed.

Not separating template sends from session sends

These are different product and API paths. Treat them differently in code, analytics, retries, and debugging.

Checklist for developers

• Store the timestamp of the latest inbound user message.
• Compute whether the service window is currently open.
• Block non-template sends outside the window.
• Provide a template fallback path.
• Store template approval state and category.
• Test sends inside and outside the window.
• Make agent and human handoff flows use the same policy gate.
• Log why a send was blocked or converted to a template.
• Show the service-window state in your UI where operators need it.

Bottom line

The 24-hour rule is not a WhatsApp trivia question. It is a core part of the send policy.

If your system sends WhatsApp messages, build around the service window from the beginning. It will make AI agents, human inboxes, broadcasts, retries, and template workflows much easier to reason about.

Kapso’s role is to make this less painful: connected numbers, templates, workflows, agents, and inbox handoff should all work inside the same WhatsApp policy model instead of making every developer rediscover the rule in production.