Skip to content

CONCEPT Cited by 1 source

Messaging platform 24-hour response window

Definition

A platform-imposed business-messaging rule in which a bot account may send free-form outbound messages to a user only within a fixed window after the user's last inbound message. Outside the window, outbound messages are either blocked, billed as paid template messages, or constrained to a pre-approved template set.

WhatsApp Business API is the canonical instance and the motivating case for this concept's inclusion on the wiki. From Vercel's Chat SDK launch:

"Note that WhatsApp enforces a 24-hour messaging window, so bots can only respond within that period. The adapter does not support message history, editing, or deletion."

(Source: sources/2026-04-21-vercel-chat-sdk-brings-agents-to-your-users.)

Why this is architectural, not just policy

The 24-hour window isn't a rate limit or throttling mechanism — it's a platform product constraint on session semantics. It reshapes:

  1. Agent response timing. An async agent that takes >24 hours to produce a response (long-running research agent, human-in-the-loop loop) can't deliver the response through the same channel. Designs have to either constrain themselves to <24h, pre-send a "holding" message to reset the window (by eliciting a reply), or fall back to paid template messages.
  2. Follow-up and proactive messaging. Bots cannot spontaneously initiate conversations or send follow-ups without a user reply. Notification-style bots (e.g. "your order shipped") need template messages, not free-form outbound.
  3. Conversation resumption. If a conversation dies for 25 hours, it's effectively a new session from the platform's perspective — even if the bot's internal state models it as continuous.

Why WhatsApp has it

The rule exists as an anti-spam mechanism for the consumer-facing WhatsApp network. Business APIs without such constraints (Slack, Discord, GitHub) don't need to protect users from unsolicited outreach in the same way — Slack bots are invited into workspaces, Discord bots into servers, GitHub bots into repos, and the user-bot relationship is framed differently.

How an SDK adapter surfaces it

The Chat SDK's WhatsApp adapter surfaces the constraint by absence: "The adapter does not support message history, editing, or deletion" — these are precisely the outbound-bot behaviours that require a live messaging window.

Rather than pretending the constraint doesn't exist (and failing silently at runtime), the adapter narrows its API surface to what WhatsApp actually supports under the window rule. This is an example of the general principle that adapters can't paper over platform product rules, only uniform quirks.

This makes WhatsApp a boundary case for the multi-platform chat adapter pattern: the unified thread.post() interface doesn't just dispatch to a native renderer on WhatsApp — it runs into a product-level cap the agent designer must anticipate.

Generalisation

Similar constraints exist on other consumer messaging platforms under business-API regimes: - Facebook Messenger Platform historically had a 24-hour + 1-message rule, now replaced by messaging tags / one-time notifications / paid messaging windows. - iMessage Business doesn't expose free-form unsolicited outbound. - SMS / A2P 10DLC in the US has opt-in and STOP-word constraints that similarly constrain free-form outbound messaging.

Collectively these are business-messaging response-window constraints — a specific sub-kind of platform-imposed constraint relevant to any chat-bot / agent architecture that spans consumer messaging networks.

Implications for agent design

  • Don't build an agent loop that depends on sending arbitrarily-timed follow-ups. Either bound the loop below 24 hours, pre-stage template messages, or fall back to a different channel (email, push, in-app notification).
  • State time since last user message as a first-class signal. The agent state should include a last_inbound_at so the agent can adjust its communication plan as the window nears expiry.
  • Testing matrix. Integration tests for a WhatsApp bot should cover the window-expiry edge case explicitly — most bot-framework test suites assume unbounded outbound.

Seen in

Last updated · 476 distilled / 1,218 read