Skip to content

Template names are validated, and inbound messages with control characters no longer disappear

Released: July 25, 2026

POST /v1/{phone_number_id}/messages Changed

Section titled “POST /v1/{phone_number_id}/messages ”

template.name is now trimmed and validated before the send is attempted. Meta accepts only lowercase letters, numbers, and underscores (^[a-z0-9_]+$).

"name": "order_shipped"    // ok
"name": "order_shipped "   // ok - trimmed for you
"name": "order shipped"    // 400 invalid_request_error
"name": "Order_Shipped"    // 400 invalid_request_error
"name": "order-shipped"    // 400 invalid_request_error

Previously the name was passed to Meta verbatim. A name carrying a stray trailing space — the usual copy-paste artifact — came back as (#131000) Something went wrong, Meta’s generic bucket. On our side that code is classified as a transient upstream fault, so the send was retried three times with the same malformed payload and then reported to you as upstream_error. The message looked like a Meta outage; it was a typo.

Two changes follow from that:

  • Surrounding whitespace now succeeds instead of failing. If your integration has been sending "kirim_hasil_mcu ", it starts working.
  • Names that trimming cannot repair fail fast, with 400 invalid_request_error naming the offending field, rather than burning three retries and surfacing a misleading 5xx. SDK users catch this as InvalidRequestError instead of ApiServerError.

If you send template names assembled from spreadsheet cells or form input, this is the case to re-check — those are the sources that carry invisible whitespace.

Webhooks — inbound messages with control characters Fixed

Section titled “Webhooks — inbound messages with control characters ”

An inbound WhatsApp message whose body contained a NUL byte (0x00) was silently lost: it never appeared in the inbox, never advanced the conversation’s 24-hour window, and never produced a message.received webhook. NUL is rejected outright by our datastore, which failed the write for the whole message; the retries replayed the same content and the message was dropped.

In practice this came from broadcast-style bodies where an emoji or formatting sequence had been mangled upstream before it ever reached us, so the sender saw a normal message and had no way to tell it had not landed.

Control characters are now stripped as the payload enters the platform. Newlines, carriage returns, and tabs are preserved, and emoji, accents, and other multi-byte text are untouched — only the characters that cannot legally be stored are removed. Affected messages now arrive normally.

No action is required on your side. If you reconcile message counts against your own records, a small number of previously-missing inbound messages around this period will remain missing: they were never persisted and cannot be recovered.

Sending templates

Webhook events