WhatsApp 24-hour window and templates, explained

According to Meta's documentation, when a user sends a message or places a call to your business, a 24-hour timer called the customer service window starts. While the window is open, the business can send messages that are not templates. Outside it, only templates. Each new customer message restarts the count.

In practice, this separates two kinds of conversation. In a customer-initiated conversation, you reply with free-form text, media and buttons while the window is open. In a business-initiated conversation (billing, notices, campaigns), the window does not exist yet or has already closed, and the first contact has to be a template. The terms are in the glossary and in the template entry.

A template is a message with text pre-approved by Meta, with variables (name, date, amount) that you fill in at send time. Meta sorts templates into categories, such as marketing, utility and authentication, and the category affects billing.

There is also a special free entry point window. According to Meta, when a user arrives through a Click to WhatsApp ad, the window can stay open for up to 7 days, and during that period marketing, utility, authentication and service messages are not charged. Check the current conditions in Meta's documentation before planning a campaign around this.

It is an error from Meta's official API, not from ZapZap. The official description is 'more than 24 hours have passed since the recipient last replied to the sender number', and Meta's suggested fix is to send a template. If you see this code, your free-form text message was sent with the window closed.

Two other codes come up in conversations on the topic. 131049 means the message was not delivered to maintain healthy ecosystem engagement, and Meta advises waiting at least 24 hours before resending the template. 131026 means the message could not be delivered, with causes such as the number not being on WhatsApp, the recipient not having accepted the latest terms or using an old version of the app. The full list is on Meta's error codes page (developers.facebook.com, WhatsApp Business Messaging documentation).

ZapZap does not return these codes, because they belong to the official API. If a code in this format shows up in your integration, it comes from an official API you are also using.

According to Meta, since July 1, 2025 billing is per delivered message, not per conversation. The business does not pay for messages users send. Per the documentation read on 10/27/2026, the first 1,000 service messages each month are not charged, and above that, charges for service messages apply from October 1, 2026. Marketing, utility and authentication messages are charged by category.

Prices in local currency change by quarter and by category, and outdated pricing on blogs is the main source of budgeting mistakes. That is why this guide does not repeat tables: check Meta's official rate card and use the site's cost calculator, which shows the date it was last checked. For a comparison of costs and ways to sign up, see the WhatsApp Business API guide.

On top of Meta's rate, the official provider (BSP) may charge a monthly fee or a markup. Add everything up into a cost per useful conversation before deciding.

The window and template rule belongs to Meta's official platform. On an unofficial API like ZapZap, you connect the number by QR code and send free-form text with no template and no prior approval, at any time. There is no Meta per-message charge in the middle, and ZapZap charges per active number, prepaid (pricing).

The trade is in risk. Without the window's guardrail, you are the one controlling behavior, and messaging people who never spoke with the company is exactly what raises the odds of reports and of the number being restricted. Unofficial use is not covered by the WhatsApp Terms, and no tool removes that risk. See the honest guide to the unofficial API and WhatsApp anti-ban.

A good practice borrowed from the official side: even with no technical guardrail, treat the 24-hour window as a rule of conduct. Reply within it, ask permission before starting a conversation and make opting out easy. Full comparison in ZapZap vs the official API.

curl -X POST "https://api.zapzapapi.com/api/v1/$INSTANCE_ID/send/text" \
  -H "x-api-key: $ZAPZAP_API_KEY" \
  -H "x-api-secret: $ZAPZAP_API_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"number":"5511999999999","text":"Olá, Maria! Seu pedido saiu para entrega."}'

Neither is the universal answer. Compare real costs at your volume and the consequences of losing the number. To decide with numbers, start with the calculator.

Picture a clinic that sends appointment reminders. On the official API, the reminder is the business's first contact, so it has to be an approved utility template, with variables for name, date and time. If the patient replies 'confirm', the 24-hour window opens and the clinic can chat freely: reschedule, send the address, answer questions. If the patient replies the next day, the window has already closed and the clinic's answer needs another template.

On an unofficial API, the same reminder is free-form text. The operation is simpler and cheaper per message, and the care shifts elsewhere: only remind people who booked, at a reasonable hour, with an easy way out. For the business owner, the useful question is not which one is cheapest, but which mix of cost, control and risk fits that part of the operation. Many companies use the official API for formal reminders and billing and the unofficial one for the support conversation.

When designing the flow, write down on paper who speaks first, when the window opens and what happens when it closes. That map avoids surprise 131047 errors on the official side and messages to people who did not expect them on the unofficial side.