WhatsApp Error 131037, and Why name_status Says DECLINED

Why does WhatsApp say my number needs display name approval?

Because the number the request was sent from has no approved display name — and, if you read Meta's current error table rather than the string your client printed, because that number is one of Meta's 555 numbers. The Cloud API error reference defines 131037 in a single sentence:

"The 555 business phone number used to send the request does not have an approved display name." (Meta — WhatsApp Cloud API error codes)

with the remedy given as "Change the 555 business phone number's display name. Also see our How to change your WhatsApp Business display name Help Center article." (Meta — WhatsApp Cloud API error codes)

The string that comes back over the wire is not that sentence. As posted in a thread on Meta's own developer community, the API returns:

(#131037) WhatsApp provided number needs display name approval
before message can be sent.

One code, two different wordings. Meta's documentation says "555 business phone number"; the response body says "WhatsApp provided number". That mismatch is why the error resists searching: the phrase you were handed appears on vendor helpdesk pages and almost nowhere on Meta's own site.

The mechanism is a six-value field called name_status, a webhook, two separate clocks, and an automatic re-check that fires months later at the worst possible moment.

• Why does WhatsApp say my number needs display name approval?
• Is 131037 your error if you are not on a 555 number?
• What are the six values of name_status?
• Why does the webhook say REJECTED when name_status says DECLINED?
• What does the phone_number_name_update webhook carry?
• Why did an approved display name go back into verification?
• What happens in the 14 days after approval?
• How many display name changes do you get?
• What should you poll to know the name is fixed?
• What Meta does not publish about display name review

Is 131037 your error if you are not on a 555 number?

Probably not, and it is worth settling first.

Meta's current definition of 131037 names one kind of number and only that kind. 555 numbers are the +1 numbers with a 555 area code that a business customer can obtain through Embedded Signup instead of bringing a real number. Meta's Embedded Signup overview states that "Business customers can claim up to two 555 business phone numbers" and describes how they behave:

"These numbers behave the same way as standard business phone numbers (subject to pricing rules, impacted by quality ratings, and so on), but must have their display names approved before they can be used to send messages." (Meta — Embedded Signup overview)

That is the sending block the error code enforces, stated explicitly and stated only for these numbers. If your number is one you own and verified yourself, and you are seeing a display-name failure, you are almost certainly looking at a name_status value surfaced somewhere other than a send call — in WhatsApp Manager, in a webhook, or in a phone number read against Graph. The state machine is the same; the sending consequence Meta documents is not.

Everything below applies to both, because name_status lives on every business phone number, not just the 555 ones.

What are the six values of name_status?

Meta's business phone numbers reference documents six, and each has a one-line definition worth quoting because most integrations are written against two of them.

(Meta — Business phone numbers)

Two of these break assumptions people carry in from vendor documentation. AVAILABLE_WITHOUT_REVIEW says plainly that a display name can be ready to use with no review at all, which is not what any page recommending you "wait for approval" implies.

And the last two are not display-name outcomes in the ordinary sense. The table shortens them to keep it readable, so here they are as Meta writes them. EXPIRED is "The phone number's certificate has expired and cannot be used to register the phone number for API use." and NONE is "The phone number does not have a certificate and cannot be used to register the phone number for API use." (Meta — Business phone numbers) Both describe a missing or lapsed certificate blocking registration — a different failure wearing the same field, and one no amount of editing the name will clear.

Checked against Meta's documentation on 11 September 2026.

Why does the webhook say REJECTED when name_status says DECLINED?

This is the single most expensive detail on the page, and it sits in two adjacent sentences of Meta's own display names documentation.

"If your display name is approved, the webhook has decision set to APPROVED, and the name_status field on your business phone number is set to APPROVED." (Meta — Display names)

"If your display name is rejected, the webhook has decision set to REJECTED, and the name_status field on your business phone number is set to DECLINED." (Meta — Display names)

Read those together. On approval the two fields agree: APPROVED and APPROVED. On rejection they do not: the webhook says REJECTED, the phone number says DECLINED. Same event, two words.

The consequence is a bug that never throws. Code written against the webhook's vocabulary, then pointed at the phone number field, looks correct and is silently unreachable:

// Never true. name_status is never the string "REJECTED".
if (phone.name_status === 'REJECTED') escalate();

// The value Meta actually sets.
if (phone.name_status === 'DECLINED') escalate();

A rejected name then reports as indefinitely pending, because the only other branch anyone writes is !== 'APPROVED' mapped to "still waiting". Nobody is alerted, the 30-day change budget below is never spent on a fix, and the number sits with a name Meta has already refused.

What does the phone_number_name_update webhook carry?

Four fields, and one of them has more values than the two sentences above suggest. Those four fields are not at the top of the payload. Meta's reference prints them inside entry[].changes[].value, three levels down, wrapped in the standard webhook envelope:

{
  "entry": [
    {
      "id": "102290129340398",
      "time": 1739321024,
      "changes": [
        {
          "value": {
            "display_phone_number": "15550783881",
            "decision": "APPROVED",
            "requested_verified_name": "Lucky Shrub",
            "rejection_reason": null
          },
          "field": "phone_number_name_update"
        }
      ]
    }
  ],
  "object": "whatsapp_business_account"
}

(Meta — phone_number_name_update webhook)

The nesting is the first thing to get right, and it fails the same way everything else on this page does. A handler that reads payload.decision gets undefined, matches neither REJECTED nor DEFERRED, throws nothing and reports nothing. Descend to entry[0].changes[0].value and check field before you branch on decision, because the same envelope carries every other WhatsApp webhook too.

decision is documented with four possible values, not two: APPROVED, REJECTED, and also DEFERRED — "Indicates a decision has been deferred" — and PENDING — "Indicates a decision is still pending further review." (Meta — phone_number_name_update webhook)

So the webhook can fire without deciding anything. A handler that treats every delivery as terminal, and branches only on approved-or-rejected, will resolve an open ticket on a DEFERRED payload. Meta does not publish a mapping from DEFERRED or PENDING on the webhook to a specific name_status value on the number, so do not infer one — log the decision, re-read name_status, and let the field on the number be the authority.

rejection_reason carries null when the name was accepted, and Meta's documented values otherwise are NAME_EMPLOYEE_ISSUE, NAME_INDIVIDUAL_ISSUE, NAME_ENDCLIENT_NOTRELATED, NAME_FORMAT_UNACCEPTABLE, NAME_NOT_CONSISTENT and UNKNOWN. Three of those six describe a name that named a person or an unrelated business rather than the business that owns the number: the first two are documented with identical text, "Rejected because the display name included a person's name or employee identifier," and the third reads "Rejected because the display name included an unrelated business's name." (Meta — phone_number_name_update webhook)

The fourth is not in that group and should not be bucketed with it. NAME_NOT_CONSISTENT is "Rejected because the display name was not consistent with the business's branding" (Meta — phone_number_name_update webhook) — a judgement about whether the name matches the business, not a claim that it named the wrong party. Telling a customer to remove a person's name when Meta refused the name on branding grounds sends them to edit something that was never the problem.

Why did an approved display name go back into verification?

Because you grew. Meta's display names page states it in one line:

"When you reach a higher messaging limit, your business phone number's display name automatically undergoes verification based on the display name guidelines." (Meta — Display names)

Nothing on your side triggers this. No deployment, no edit, no new submission. The number crosses a messaging tier — Meta's published ladder runs 250, 2,000, 10,000, 100,000 and Unlimited (Meta — Messaging limits) — and the name that has been fine for eight months is assessed again.

This is not a new-number setup problem. It selects for mature, high-volume numbers, and it arrives at the exact moment volume is rising, which is when nobody is looking at a profile field.

Worse, the two Meta pages disagree by omission. The messaging limits page sets out the tiers and never mentions display names; only the display names page carries the re-verification sentence. A team planning a scale-up from the tier documentation has no reason to expect it. If a tier change has already cost you something else, a messaging limit cut by a template category change is the sibling failure worth reading alongside this one.

What happens in the 14 days after approval?

Approval is not the end of the process, which is where almost every competing page stops. Meta's display names documentation gives a deadline:

"After the display name change is approved, you have 14 days to re-register the phone number." (Meta — Display names)

and, separately and repeatedly:

"Re-registering before approval has no effect." (Meta — Display names)

The registration guide puts both halves in one sentence: "After approval, re-register your phone number using the endpoint below. Re-registering before approval has no effect, so wait for approval first." (Meta — Register a business phone number)

Both halves trap people in opposite directions. A team that re-registers immediately after submitting gets a call that succeeds and changes nothing, concludes the API is broken, and retries. A team that waits passively for the name to "start working" lets fourteen days pass with no alert anywhere, because nothing fails during a window that is simply elapsing.

And retrying is not free. The same registration guide states: "Requests to the registration endpoint are limited to 10 requests per business number in a 72-hour moving window," with the consequence that "If you have already made 10 requests, the API will return error code 133016" (Meta — Register a business phone number).

The shape of the trap follows: the no-op re-registrations you make before approval come out of the same budget you need after it. Ten wasted calls while waiting, and the window you were waiting for opens onto a locked endpoint.

How many display name changes do you get?

Ten, per number, per month. Meta states it flatly: "You can change a display name 10 times per 30-day period." (Meta — Display names)

That budget counts attempts, not approvals. A team that submits a name, gets DECLINED, shortens it, gets DECLINED, drops a word, gets DECLINED, and keeps iterating is spending a monthly allowance on guesses. Ten is reachable in a single bad afternoon, and there is no documented way to buy more.

Meta's guidance is to check the name against its display name guidelines before submitting rather than after being refused. Those guidelines live in a Help Center article Meta publishes separately and are not reproduced here, because that page renders its body client-side and this article only quotes text it actually read. Read it at source before your first submission, not your fourth.

What should you poll to know the name is fixed?

The field, not the webhook — and specifically name_status on the phone number, compared against the six documented values rather than against a guess.

The practical order is short. Subscribe to phone_number_name_update so you learn something happened. On every delivery, read decision, and if it is DEFERRED or PENDING, treat it as information rather than an outcome. Then read name_status on the phone number itself and branch on all six values. Treat APPROVED and AVAILABLE_WITHOUT_REVIEW as success, DECLINED as a rejection needing a human, PENDING_REVIEW as waiting, and EXPIRED or NONE as a certificate problem that has nothing to do with the name. If the read itself fails rather than returning a value, the Graph error that refuses to say whether an object exists is the more likely cause than anything on this page.

This is also why a dashboard's cached status is not evidence. Most platforms, WabaCRM's included, read a number's state from Graph on a schedule and render what they last saw. The display name changes without any traffic passing through your system, so a cached row can read fine an hour after the name was refused.

Force a live read before you believe a status. When a number looks healthy on screen and behaves otherwise, the gap between a dashboard saying connected and nothing sending usually comes down to a field nobody re-read.

What Meta does not publish about display name review

Three absences are worth stating plainly, because vendor pages fill all three with invention.

No review duration. No Meta page consulted for this article publishes a turnaround time for display name verification — not a maximum, not a typical, not a minimum. The "a few minutes to several working days" range repeated across helpdesk pages traces to no Meta source found here. Do not plan a launch around a number nobody has sourced.

No mapping for DEFERRED. The webhook documents the value and describes it as a deferred decision. It does not say what name_status reads while a decision is deferred. Re-read the field rather than assuming.

No stated sending consequence for a standard number. Meta documents the sending block for 555 numbers. Nothing found here says an ordinary registered number stops sending when its name is later declined. That silence is not permission to assume either way — it means the documentation does not answer it, and your own account is the only evidence available.

A display name is also not a verification badge, though the two get conflated constantly: what the green tick, the blue tick and Meta Verified each actually are is a separate question from anything name_status describes.

Every Meta quotation on this page was read from Meta's own documentation on 11 September 2026. Meta changes that documentation without notice; the linked pages are authoritative and this one is not.