Error 131037 is a send refusal. The message does not go out. Meta defines it for a 555 business phone number that does not have an approved display name (WhatsApp error codes). [Docs]
In a real Embedded Signup case (28-30 Sep 2026), that refusal hit both approved templates and plain text replies inside an open 24-hour window. [Observed] On a Meta-provided +1 555 number whose display name was not yet approved, Meta support said messaging stayed capped at five messages per day until the name was approved and "reflected," which they said can take one to two business days. [Meta support] For anything customer-facing, use a real, verified phone number anyway.
Confidence tags in this piece: [Meta support] · [Observed] · [Docs] · [Inference]. We never upgrade Inference or a support-only claim into "Meta documentation says."
What does error 131037 mean?
Meta's public wording: the 555 business phone number used for the request does not have an approved display name. Fix path: change or approve the display name. [Docs]
The API text we saw was: (#131037) WhatsApp provided number needs display name approval before message can be sent. [Observed]
It is a refusal, not a soft warning. One Meta support agent first said it was "just informing you" and should not stop sends. That was wrong for this case. A later agent apologised and corrected it. [Meta support]
In the case, 11 plain text replies and 4 template sends all failed with the same code. [Observed] Meta's error page does not carve out "templates only," so treat any outbound send on that 555 number as in scope until the display name is approved. [Docs] / [Observed]
Separately: always check account health (and billing) before you act on a code alone. An earlier, different incident once showed 131037 when the real problem was a declined payment method. Meta documents payment-related send failures under other codes (for example 131042), so treat health and billing as part of diagnosis, not a rewrite of what 131037 means in Meta's error list. [Observed, earlier incident] / [Docs]
Why do Meta's screens and the API disagree?
Query health on the phone-number node: GET /{phone-number-id}?fields=health_status. Prefer that over the account node, which can omit the phone-number entity. [Observed] Meta's Health Status docs describe a rollup can_send_message and entities such as PHONE_NUMBER, WABA, BUSINESS, and APP, with values AVAILABLE, LIMITED, and BLOCKED. Read both errors and additional_info. [Docs]
In practice, the rollup follows the worst entity. A healthy account behind an unverified business can show LIMITED overall. That is a steady state, not an outage. [Observed] / [Docs]
On the same problem number, the phone-number fields we read included: status CONNECTED, code_verification_status VERIFIED, platform_type CLOUD_API, name_status / new_name_status both AVAILABLE_WITHOUT_REVIEW, displayed messaging limit consistent with a 250-class ceiling, quality GREEN, and verified_name still showing the old name. [Observed] Note: Meta has deprecated messaging_limit_tier in favour of whatsapp_business_manager_messaging_limit for current teaching; the case table used the older field label. [Docs] / [Observed]
At the same time, those surfaces contradicted each other [Observed]:
- The phone-number node said no review was pending (
AVAILABLE_WITHOUT_REVIEW). - Health said the display name was not approved.
- WhatsApp Manager's Phone numbers tab said "Pending review."
- Meta had emailed that a display name was approved earlier that day.
- The displayed limit looked like a normal 250-class tier while the effective behaviour matched a tiny cap.
Lesson: the approval email, Manager, phone-number node, and health endpoint update independently and can disagree for hours or days. Meta support explained the lag as approval needing to be "reflected," which they said can take 1-2 business days. [Meta support] That timing is support's answer for this case, not something we found in Meta's public docs.
Is the +1 555 number a test number?
Meta provides 555 business phone numbers through Embedded Signup (US +1 / 555). They are auto-verified. A business can claim up to two. They must have display names approved before they can send. Once the display name is approved, Meta says they otherwise behave like standard Cloud API numbers. They cannot be migrated for use outside the platform. [Docs] (Embedded Signup overview)
For evaluation that is fine. For production and portability, use your own real number. [Docs] / practice recommendation.
What Meta support said about this number: it was a +1 555, the display name was not approved, and "the WABA associated with this phone number ID remains subject to a messaging limit of five messages per day." They said it "will let you scale once the display name was approved and reflected that may take to 1-2 business days." [Meta support]
That five-per-day cap and the reflect lag come from Meta support for this case. We could not verify that exact cap in Meta's public error, 555, or messaging-limits pages. [Inference] on public-doc silence.
The case data fit a five-message ceiling (five delivers/reads on day one, then failures including more than 24 hours later). Whether that resets by calendar day, rolling window, or lifetime total is unconfirmed. [Inference / HOLD]
Why does the displayed messaging limit not match what you can send?
WhatsApp Manager showed a normal business messaging limit (about 250 business-initiated conversations in a rolling 24-hour period outside the customer service window; see Meta's live messaging limits for current numbers). Routes to higher limits include business verification and sustained high-quality conversations. [Observed] / [Docs]
That displayed figure was not the effective limit for this +1 555 with an unapproved display name. Support's effective cap was five messages per day. [Meta support] / [Observed] So treat a displayed tier as a ceiling for a normal number, not a guarantee on a 555 whose display name is still blocked.
What traps show up while you debug?
- Two accounts with the same name. The selector showed two WhatsApp Business Accounts both named the same way, with different IDs. The approval email named the account by name only. Compare account IDs, not display names. [Observed]
- The approval email names the account, not the number. Display names are tracked per phone number. An email can refer to a different number or account than the one you are testing. [Inference]
- A pending or not-yet-reflected display name can still block sends on a 555 after an earlier stretch of successful sends. [Observed] / [Meta support]
- Tell support it is a +1 555 up front. The final agent said they had not investigated the phone number ID properly until they noticed it started with +1 555. Paste the phone number ID, account ID, exact error text, and failure timestamps. [Meta support]
- Screenshots help support; IDs help you. Many sending tools do not keep every Graph error field. If you need a fresh
fbtrace_id, reproduce the call yourself (next section). Meta can often locate failures from the phone number ID and timestamps without it. [Docs] / practice
How can you reproduce the failure outside your software?
To see whether the refusal is Meta's or your sender's, replay one send with a tool you control (Postman, or Meta's Graph API Explorer).
POST https://graph.facebook.com/v21.0/{phone-number-id}/messages- Header
Authorization: Bearer {token}, headerContent-Type: application/json - Body:
{
"messaging_product": "whatsapp",
"recipient_type": "individual",
"to": "<recipient number, digits only>",
"type": "text",
"text": { "preview_url": false, "body": "test" }
}
In Graph API Explorer: choose your app, User Token, add whatsapp_business_management and whatsapp_business_messaging, generate a token, and allow the correct WhatsApp Business Account. Never paste the token into a support chat.
If the call fails with 131037, the refusal is Meta's for that number regardless of sender, and the response includes a trace ID. If it succeeds, the difference is in the original sender or token scope.
Caution: on a capped 555, each test message can spend the allowance. [Meta support] / [Observed]
What should you do?
- For anything customer-facing, use your own real phone number that can receive a verification call or SMS. Keep the +1 555 for evaluation, or remove it. Meta does not bill for the Meta-provided number itself. [Docs]
- Submit a display name early on the number you will use. Approval and reflection can take time; support cited one to two business days for reflection in this case. [Meta support] / [Docs]
- Complete business verification if you need limits above the starter tier. Prefer Meta's current messaging-limits page for the live numbers. [Docs]
- Before you scale, confirm the effective limit, not only the displayed one. Send a small batch and watch for failures. [Observed]
- Do not rely on the approval email alone. Confirm on the phone-number node that
verified_nameis the approved name, and that health no longer says the name is unapproved. [Observed] / [Meta support]
Once a 555's display name is approved, Meta says it otherwise behaves like a standard number. Still prefer a real number for production and portability (555 numbers are not migratable outside the platform). [Docs]
What did Meta leave unanswered?
| Question | State of the answer |
|---|---|
| Does 131037 block sending? | First agent: no. Later agent: limited to five per day until the name is approved and reflected. [Meta support] |
| Will a +1 555 send normally after approval? | Meta docs: yes, once the display name is approved (subject to normal limits). Support: scale once reflected, 1-2 business days. [Docs] / [Meta support] |
| Exact five-message reset rule (calendar day, rolling, total) | Not answered. HOLD |
| Which account did the approval email belong to? | Not answered. |
| Can a +1 555 display name be approved? | Meta docs require approval before send; support implied yes. [Docs] / [Meta support] |
Sources
- Meta for Developers, WhatsApp error codes (131037)
- Meta, Embedded Signup: 555 business phone numbers
- Meta Business Help Center, About WhatsApp Business Display Name
- Meta, messaging limits / health status / display-name phone-number fields (live docs as of 2026-09-30)
- 360dialog, Meta provided +1 555 phone numbers and Display names (third-party; Meta + support supersede where they conflict)
- First-hand observations: Graph API phone-number and health responses, Meta support chat, and sending records, 28-30 Sep 2026
Next step
If you are still on a Meta +1 555 for customer traffic, connect a real verified number and submit its display name before you scale.
