Error 131047: Re-engagement Message Outside the 24-Hour Window

Error 131047 means a business tried to send an ordinary chat message to a customer whose 24-hour service window has already closed, and WhatsApp refuses it. The fix is always the same: send an approved template to reopen the conversation, and the window reopens the moment the customer replies.

Symptom

An API call or integration attempting to send a free-form (non-template) message returns error 131047, with Meta's title along the lines of "re-engagement message" or a description naming the closed customer service window. Inside VGraple CRM's own inbox, this scenario is largely designed around, not encountered as a raw error: when an agent opens a conversation whose 24-hour window has lapsed, the message composer prompts for a template instead of accepting free text, so the failure itself is rare on the platform's own send paths. It shows up most often from a direct API integration, a webhook-driven automation, or an older workflow that builds and sends its own payload without checking the window first.

Why it happens

WhatsApp's customer service window is 24 hours from the customer's most recent message. Inside that window, a business can send as many free-form messages as it wants, no template required, at no extra charge beyond the conversation itself. Outside it, WhatsApp only accepts pre-approved templates, because Meta's policy is built to stop businesses from messaging people who have gone quiet using ordinary chat text, which is exactly the kind of unsolicited contact templates and their review process exist to police.

Crucially, the window only resets on a message from the customer. A business agent replying inside the window does not extend it, and an automated flow or sequence sending the customer something does not extend it either. If a customer messages at 10 AM and an agent does not reply until 11 AM the next day, the window closed at 10 AM that morning, an hour before the reply, and that reply itself will fail with 131047 unless it is sent as a template.

Fix

1. Send an approved template instead of free text. Any UTILITY or MARKETING template already approved for your WhatsApp Business Account can go to a closed-window conversation; there is no special "re-engagement" template type required by Meta beyond an ordinary approved one.
2. Use the inbox's own prompt if you are working manually. VGraple CRM's conversation view detects a closed window and switches the composer to offer template selection directly; see sending a template from the inbox outside the 24-hour window for the exact steps.
3. If you are calling the API directly, check the window before sending. Read the timestamp of the customer's last inbound message from the conversation record and compare it against 24 hours before attempting a free-form send; if it has closed, send a template call instead.
4. Wait for the customer to reply to the template. Once they respond, in any form, even a single word, the 24-hour window reopens and ordinary free-form messages work again until it next closes.
5. For a recurring workflow (a webhook, a legacy integration), fix the payload builder once. A one-off manual send is a minor inconvenience; a scheduled job that keeps hitting 131047 on every run means the integration needs the same window check the inbox already has.

How VGraple CRM handles it automatically

Every send path built into the product, the inbox composer, chatbot flows, automation rules and sequences, checks the customer service window before attempting a free-form send and automatically routes to a template when the window has closed, rather than letting the send reach Meta and fail. This is why 131047 is uncommon in normal day-to-day use of VGraple CRM: the failure it represents is designed around at the point of composing the message, not caught afterward. A flow node that would otherwise send plain text to a contact outside the window is redirected to its configured fallback template automatically, and the inbox shows agents a template picker the moment the window has lapsed rather than letting them type into a composer that will fail.

Where 131047 can still occur is on the REST API for organisations that integrate directly and build their own send calls; in that case the failure is returned to the caller exactly as Meta sent it, with no VGraple CRM-side interception, since the API is intentionally a thin, faithful layer over WhatsApp's own rules for developers who want that control. See the REST API quickstart for how to check window state before sending.

Prevention

The most reliable prevention is responding inside the window in the first place: SLA targets and breach alerts can flag a conversation approaching its 24-hour deadline before it closes, giving an agent a chance to reply while free-form is still possible. For automated flows, always configure a fallback template for any step that might fire outside the window, rather than assuming the customer will always be recently active. For a direct API integration, treat the customer's last-inbound timestamp as a first-class field to check before every send, not an edge case to discover from a 131047 in production.

What if the window closes mid-conversation with an active customer?

This happens more often than it seems, particularly for slower-moving purchases like real estate, education enquiries, or B2B sales where a customer might go a day or two between messages without any intent to disengage. The correct response is not to worry about "losing" the conversation, since nothing about the relationship or the contact's data changes when the window closes, only the send method does. Send a single, low-friction UTILITY template that makes sense as a natural continuation ("following up on your enquiry about X" rather than a hard sales push), and once they reply, the conversation is exactly where it left off, with full message history intact and free-form messaging available again for as long as the new window stays open.