WhatsApp API Errors: 131047, 131026, 131049 and More

Errors 131047, 131026, and 131049 are responses from Meta, not from your provider: 131047 means you tried to send a free-form message with the 24-hour window closed, 131026 means the destination number has no active WhatsApp, and 131049 means that person already received too much marketing, summed across all companies, and Meta held yours back. Each code says whose rule it is and what to do, and that is what this dictionary organizes. None of them is charged, because Meta only charges delivered messages.

Short answer: how to read a Meta error

Every send through the official API ends one of three ways. Meta accepts it and returns a message id. Meta refuses right away, with an error code in the response. Or Meta accepts and gives up later, and the failure arrives by webhook, in a failed status with the same kind of code. A webhook is the notification Meta sends to the provider's server when something happens to a message.

To read the code, ask three questions, in this order:

1. Whose rule is it? Meta as a platform, the recipient, your number, or your account. That decides whether there is anything to fix on your side.
2. Does resending help? For most codes in this article, no. Resending blindly repeats the failure and, in two cases, makes things worse.
3. What changes the result? An approved template, a 24-hour wait, removing the contact from the audience, registering a card, reconnecting the number. Each code has only one way out.

Through the Frame Conexa API the refusal arrives as a 502 with Meta's error object attached under graph. It is the same object Meta returns, untranslated, because the code is the most useful clue there is:

{
  "error": "a Meta recusou o envio",
  "graph": {
    "code": 131049,
    "message": "This message was not delivered to maintain healthy ecosystem engagement."
  }
}

When the failure comes after acceptance, it arrives through your outbound webhook, in the messages event, inside statuses[].errors. The dashboard reads both paths and shows the reason next to the recipient. The limits of the Frame Conexa API itself, which are request limits and not message limits, are in errors and limits and should not be confused with the codes here.

Window and template errors

These are the errors of someone who tried to send the right thing at the wrong time, or the wrong thing in the right format. The rule behind them is the most basic one of the official WhatsApp API: the company can only write whatever it wants inside a window opened by the customer. Outside it, only a template, which is a fixed-text message approved by Meta before sending.

131047: outside the 24-hour window

The official description is that more than 24 hours have passed since the recipient's last reply. You tried a free-form message, text or media, and the 24-hour window was closed. Meta refuses it right away. The message does not go out and is not charged.

The window belongs to WhatsApp, not the provider, and does not open through insistence. Resending gives 131047 again. The way out is a Meta-approved template: utility to resume a support conversation, marketing for an offer. If the person replies to the template, the window opens and free-form conversation is valid again.

There is a longer window in one case only. Someone who arrives through a Click-to-WhatsApp ad and gets a reply within 24 hours opens a 72-hour window in which any message is free. With coexistence, that window is only born when the reply goes out through the API: according to Meta, messages sent from the phone app do not open or extend the API's windows. Error 131047 remains Meta's answer when it considers the window closed, whether it is a 24- or 72-hour one.

Important: starting 10/01/2026, Meta begins charging per message for free-form replies inside the 24-hour window and for utility templates sent inside it. The window rule does not change. What changes is that "inside the window" stops meaning "free." Check Meta's official rate card when publishing prices.

132000 and 132001: template with wrong variables or nonexistent in the language

Codes starting with 132 are about badly built templates. 132000 says the number of variables sent is not what Meta approved: the template has two slots to fill and the send provided three, or one. 132001 says the template does not exist in the requested language, or is not approved in it. A template approved in Portuguese and sent as en_US lands here.

Both are integration errors, and so they are the only ones in this article where resending solves it, as long as the send is corrected first. A template paused by Meta for low quality is also rejected right away, and the way out is different: revise the template, not the send.

Recipient errors

Here your number is fine and your template is fine. The problem is on the other end, and the provider cannot know before trying. That is why every campaign to a cold list ends with a slice of failures from this group, and why that slice is not a sign of malfunction.

131026: not a WhatsApp user or hasn't accepted the terms

Meta could not deliver because the number has no WhatsApp, or the person has not yet accepted the app's new terms, or uses a version that is too old. All three cases come with the same code, and none is solved on your side.

The action is to remove those contacts from the audience. Resending gives the same result, and a list with many 131026 is an old list: numbers that changed owners or never had WhatsApp. If the list came from an import, it is worth checking its source before the next campaign.

131049: per-person marketing limit, wait 24 hours

The official message is that the message was not delivered to maintain a healthy ecosystem engagement. Behind it is a limit Meta applies per recipient: how many marketing templates the same person can receive in a period, summed across all the companies that talk to them. The number is not disclosed. Meta describes the limit as dynamic, based on how much that person has been reading the marketing messages they receive.

That limit is neither your number's nor the provider's, and no dashboard can predict the error, because nobody knows how many marketing messages that person received from other companies today. Meta's guidance is to wait at least 24 hours before trying again. Resending earlier can extend the block by another 24 hours. Utility and authentication templates do not count in this tally, and neither do messages inside a window opened by the person.

The API messaging limits article explains how this per-person limit coexists with your number's capacity, which is a different limit, also Meta's, and which does show up in the dashboard before sending.

131050: the person asked not to receive marketing

The recipient turned off, in WhatsApp itself, receiving marketing messages from your company. Meta refuses delivery and reports their preference. There is nothing to resend: the decision is the person's, and insisting through another path goes against Meta's messaging policy.

In Frame Conexa the contact leaves the audience automatically when this code arrives. Meta also reports the preference through a webhook of its own, user_preferences, which the dashboard subscribes to, so the removal from the audience happens even when the person changes the preference without you having sent anything. Someone who accepts marketing again returns to the audience on their own. Only a suppression done by hand by your team is not undone by webhook.

130472: Meta experiment, do not resend

The official description is that the message was not sent as part of an experiment. Meta maintains a small group of users who do not receive marketing messages from companies they have never talked to. It is a test of Meta's, with no disclosed end date and no way for the company to opt out.

Resending fails again. That person only receives if they message first, which opens the 24-hour window and takes the send out of the cold marketing category. In practice, it is worth removing them from the campaign audience and letting them arrive through another channel, such as an ad or a link.

Number and account errors

In this group the problem is on your side of the table: in the sending pace, the number's health, the account's payment, or the authorization the number gave the provider. These are the only errors in the article that call for an action from you before the next send.

130429: too fast

Meta refused due to too many sends per second. The per-number cap is Meta's: a number in coexistence, which stays in the phone app, is fixed at 20 messages per second, and an API-only number starts higher and rises on its own with usage. Frame Conexa serializes sends per number within that cap and retries once on a 130429, so the code only reaches you when the automatic attempt also failed.

The action is to resend at a lower pace. A cousin of it is 131056, which limits how many messages a number sends to the same person in a short time: the way out is to wait a few minutes before sending to that contact again.

131048: quality restriction, Meta asked to stop

Meta detected a high spam rate on that number and held the sends. This is the quality restriction: recipients blocked, reported, or marked the number as unwanted in recent days, and Meta responds by reducing what it can send. Since October 2025, low quality no longer downgrades the capacity the number has already earned. What it does is block moving up, pause low-quality templates, and trigger this restriction.

Here resending is the worst possible move, because each refused attempt reinforces the signal. In Frame Conexa a campaign that receives 131048 is paused on its own. The action is to slow down, review the audience, remove anyone who did not give permission, and only then resume. The article on blocked WhatsApp Business shows what happens when this signal is ignored for too long.

131042: payment problem on the Meta account

The send failed because the WhatsApp Business account at Meta has no valid payment method: card not registered, credit limit exceeded, or billing line inactive. It is the error that most surprises people who just connected, because the number is green, the template is approved, and still nothing goes out.

Meta charges the customer directly for delivered template messages, and as a Tech Provider Frame Conexa does not register payment on the customer's behalf: you register the card yourself, in your own Business Manager. The dashboard checks the account's health before creating a campaign, warns when it is blocked for payment, and hands over the Business Manager link to fix it. After the card is registered, the next send goes out without reconnecting anything. The API payment method guide shows where to register and the most common problems along the way.

133010: number not registered

The number is not registered on Meta's platform. This code is rare in coexistence, because the phone app itself already registered the number. It shows up on a new, API-only number, when the registration step did not happen or was undone. In Frame Conexa registration is part of connecting a new number, and the way out of a 133010 is to reconnect the number under Instances.

190: authorization revoked, reconnect

190 is not about the message. It is about the token, the credential your number gave the provider when you authorized the connection. It expired or was revoked: someone removed the partner in Business Manager, the account was restructured, or the authorization dropped for another reason on Meta's side. Until it is redone, no send goes out and no inbound message arrives.

On seeing a 190, Frame Conexa marks the instance as disconnected, emits the instance_status event with disconnected on your outbound webhook, and the API starts answering 409 with a request to reconnect. Reconnecting is the same flow as the first time, Embedded Signup, from the dashboard. The conversation history and the audience stay where they were.

Summary table: code, whose it is, what to do

It is worth reading by column. The "whose rule" column shows that only four rows are yours. The "resend" column shows that, of the thirteen, resending without changing anything solves none.

How the Frame Conexa dashboard shows each reason

The dashboard does not show the code alone. Each failure appears in three pieces: a short label, an explanation that says whose refusal it is, and an action you can execute on screen. 131049 appears as "Meta per-person limit," with the explanation that the limit applies per recipient and not to your number, and the action "wait at least 24 hours." 130472 appears as "Meta experiment." 131047, as "window closed," with the action "send an approved template."

This dictionary was born from a real campaign. In September 2026, a bulk send to 250 cold contacts ended with 36 failures, all 131026, 130472, or 131049. The screen showed the code number and a text that talked about a "marketing limit per recipient" without saying that the limit was Meta's. The natural suspicion of anyone paying per number is that the limit belongs to the provider, and the screen left room for that. The dictionary exists to remove that doubt before it becomes a support ticket.

Three automatic behaviors complete the dictionary:

• 131050 suppresses the contact. Anyone who asked not to receive is removed from the audience immediately, and the automatic suppression is undone if the person accepts again. Your team's manual suppression is never undone by webhook.
• 131048 pauses the campaign. Meta said stop, and the dashboard stops. Resuming is an action of yours, after reviewing audience and pace.
• 190 disconnects the instance. The status changes to disconnected in the dashboard, in the outbound webhook, and in the API, in a single event per transition. Reconnecting turns everything back on.

For the "Failures by reason" card, which groups the whole campaign by code, the footer reminds you that Meta only charges delivered messages. To someone who does not know the API, "failure" sounds like lost money, and it is not.

There is also a fourth state, which has no Meta code: the uncertain result. When Meta does not respond in time, the send may or may not have gone out. The API returns the error with ambiguous: true, and the instruction is not to resend blindly, because the message may be duplicated. In the dashboard these sends appear as "uncertain," and the "Resend uncertain" button checks before repeating. Anyone integrating through the API can send an Idempotency-Key with the send, and repeating the same key returns the result of the first attempt instead of creating a second send.

For anyone handling the outbound webhook in code, the decision by code fits in a few lines. What matters is separating what leaves the audience, what waits, and what calls for human action:

function decidir(codigo) {
  switch (Number(codigo)) {
    case 131026:
    case 130472:
    case 131050:
      return 'remover-do-publico';
    case 131049:
      return 'tentar-depois-de-24h';
    case 130429:
    case 131056:
      return 'tentar-mais-devagar';
    case 131047:
      return 'usar-template';
    case 131048:
    case 131042:
    case 133010:
    case 190:
      return 'acao-humana';
    default:
      return `erro ${codigo}`;
  }
}

An unknown code still comes out as the code itself, never as a "generic error." A code without a translation is still a clue: you can look it up in Meta's official list of error codes.

Next step

If you operate through the API, the reference for HTTP status, rate limits, and the uncertain result is in errors and limits. If you operate through the dashboard, the reason for each failure already appears next to the recipient, with the right action. To connect a number and see this working, see the per-number plans.