WhatsApp errors

Error 131049 — WhatsApp refused the message for this one person

The message says Failed to send, and under it WhatsApp's own words begin with 131049. Meta withheld this message from one person because of how many messages of this kind they have already been sent. The important part is what it is not. It is not your number being blocked, not your template being wrong, and not a fault in the connection. Messages to other people keep going out normally in the same minutes — that is exactly what was observed when this was first investigated here, with delivered and read messages interleaved with the refusals on the same number. Why Retry is not offered For this code the Retry button is deliberately withdrawn and replaced with the reason. The restriction follows the person, not your configuration. Nothing you change about the message, the template or the number makes Meta accept the same message to the same recipient, so pressing Retry would simply collect the refusal again — and every attempt is one more signal against your number's quality rating. See quality rating and messaging limits. Other failures keep their Retry. Only refusals that follow the recipient lose it. What to do Nothing, for that message. The cap is Meta's and it lifts by itself. There is no setting here or in WhatsApp Manager that raises it, and no support request that clears it for one contact. What you can do is reduce how often you hit it: - Send fewer marketing messages to the same people. The cap counts what a person receives, so a narrower audience and a longer gap between campaigns both help. - Use the right template category. A message genuinely about one transaction belongs in UTILITY, which this cap does not apply to the same way. Do not relabel marketing as utility to get around it — Meta reads the content, and a template submitted in the wrong category is rejected or reclassified. - Reply inside the conversation instead. Within the 24-hour window you are answering a customer rather than marketing to them. A worked example A shop sends a promotion to 4,000 contacts. The campaign completes; 37 messages failed, all with 131049, and the same contacts received the shop's order-confirmation messages that afternoon without trouble. There is nothing to fix. The shop stops sending promotions to contacts who received one in the previous fortnight, and the count on the next campaign is much lower. Who can do this Any agent can see the explanation on the message. Changing audiences, templates and campaign scheduling is an administrator's job — see roles and permissions. Limits - Lynomia Chat cannot tell you how close a contact is to the cap. Meta does not report that, so the first sign is the refusal. - The refusal is per message. The same contact may receive the next one. - There is no list of restricted contacts anywhere in the product. - A campaign reports the failure per message, so a mostly successful campaign can still contain these. Related - When WhatsApp does not work - Quality rating and messaging limits - The WhatsApp 24-hour window - WhatsApp campaigns - The template lifecycle

Error 131042 — the WhatsApp Business account cannot be billed

The message failed and WhatsApp's words begin with 131042. The WhatsApp Business account's payment setup is not usable — most often no payment method, a card that was declined, or a currency that does not match the account. This is the one in this section that is genuinely yours to fix. It is about the account, not about the person you were writing to, so it stops every paid message on that number rather than one. Why Retry stays available Unlike 131049, the Retry button is kept. The reason is simple: an administrator can fix the billing in Meta Business Manager, and the same message will then send. Withdrawing Retry here would be telling you to give up on something you are about to be able to do. Lynomia Chat does not re-send it for you. Nothing here retries a WhatsApp message on its own; after you have fixed the billing you press Retry on the message yourself. What to do 1. Open business.facebook.com and go to the WhatsApp Business account for this number. 2. Check Billing — a payment method must be present and valid, and the account's currency must be set. 3. Fix whatever is missing. A declined card and an unset currency look identical from here. 4. Come back to the conversation and press Retry on the message. Nothing in Lynomia Chat changes this. There is no billing screen here for your WhatsApp account, because the money relationship is between you and Meta. A worked example Messages stop sending on the first of the month, all with 131042. The administrator opens Business Manager and finds the card on the WhatsApp Business account expired. They add a new one, return to the three conversations where an agent was mid-reply, and press Retry on each. All three go out. No template needed re-approving and no number needed reconnecting, because nothing was wrong with either. Who can do this An administrator of the Meta Business Manager account — which may not be the same person as a Lynomia Chat administrator. An agent can see the refusal and press Retry, but cannot fix the cause. Limits - There is no warning before it happens. Lynomia Chat learns the billing is unusable when Meta refuses a message. - Account Health does not report billing. The number can look entirely healthy and still refuse every paid message — see when WhatsApp does not work. - Messages that failed while billing was broken are not sent automatically once you fix it. Each one is retried by hand. - A campaign that ran during the outage does not resume. Check what failed and send again. Related - Error 131049 - When WhatsApp does not work - WhatsApp campaigns - Roles and permissions

Error 131053 — WhatsApp could not fetch the file

131053 means WhatsApp tried to download a file from your installation and could not. It is a transport problem between Meta and whoever hosts your server, not a problem with the attachment. You should rarely see it, because Lynomia Chat avoids the situation that causes it. Why you rarely see it There are two ways to send a file on WhatsApp: give Meta a URL and let it fetch the file, or upload the file to WhatsApp first and send it by its media id. Lynomia Chat uploads first and sends by id. The reason is exactly this error: Meta's download path is rate limited per destination network, so on shared hosting your installation can be throttled because of traffic that has nothing to do with you. The refusals that follow are intermittent, which makes them look like a fault in your own file when they are not. Uploading removes Meta's download from the path entirely. If you do see it It means the upload itself did not happen or did not finish, and the send fell back to something Meta had to fetch. Check, in this order: | Check | Where | |---|---| | Is the file very large or very slow to read? | the attachment in the conversation. An upload has a long but finite timeout | | Did the number stop being connected mid-send? | Settings → Inboxes → the inbox → Account Health | | Is this one message or every message with a file? | the conversation list, filtered to failed messages | Press Retry on the message. Because the cause is intermittent, a retry genuinely can succeed here — which is the opposite of 131049, and why Retry is offered. Who can do this An agent can retry the message. Reading Account Health and changing anything about the inbox is an administrator's job. Limits - Lynomia Chat cannot raise Meta's rate limit. It is per destination network and not something an account setting reaches. - The file is not re-uploaded in the background. A retry repeats the whole send. - Repeated failures on every file point at the host rather than at WhatsApp. That is a conversation with whoever runs your server, and the operator's diagnostic is where the evidence is — see when WhatsApp does not work. Related - Error 131049 - When WhatsApp does not work - Work in the inbox

Error 131060 — an incoming message WhatsApp will not hand over

A customer sent you something and the conversation shows an incoming message with no content. WhatsApp delivered the event but refused to hand over the message itself, marking it unsupported — the code behind that is 131060. It happens with message types WhatsApp will not forward to a business API: some interactive and system message types, and media WhatsApp itself could not process. Why there is a placeholder at all Lynomia Chat records the empty message on purpose rather than dropping the event. A dropped event would leave your agent reading a conversation where the customer appears to have gone quiet, and the customer insisting they wrote. The placeholder says, truthfully, that something arrived at that moment and could not be shown. It also keeps the conversation's timing honest: the 24-hour window opens from the customer's message, and that is still what happened. What to do Ask. The customer can see what they sent; you cannot. A single line — "something came through that we could not open, could you send it as a photo or describe it?" — resolves almost all of these, and you are inside the 24-hour window because they just wrote to you. Do not treat it as a fault in your inbox. Other messages in the same conversation arrive normally. A worked example A customer forwards a product from a shopping catalogue. The agent sees an empty incoming message and asks what it was. The customer types the product name. The agent answers, and the conversation continues. Nothing was misconfigured and nothing needed fixing. Who can do this Any agent working the conversation. There is nothing for an administrator to change. Limits - The content cannot be recovered, by you or by support. WhatsApp did not send it. - There is no notification. The placeholder sits in the conversation like any other incoming message. - It is not reported as a failure anywhere, because nothing of yours failed. - Some unsupported types carry no useful hint at all about what was sent. Related - Work in the inbox - The WhatsApp 24-hour window - When WhatsApp does not work

Error 190 — the WhatsApp access token is no longer valid

190 is Meta saying the credential is no longer accepted. The token expired, was revoked, had a permission removed, or belongs to an app that changed. It is not about a message or a template: once it happens, nothing on that number works. What Lynomia Chat does with it Two authorization refusals in a row and the inbox is marked as needing reauthorization. That threshold exists so one bad moment does not raise an alarm, and two does. When it trips: - a banner appears at the top of the dashboard saying you will not receive new messages until the connection is restored, - the account's administrators are emailed, - incoming messages are still accepted and stored. A broken outbound credential does not make Lynomia Chat throw away what customers send you — that was deliberate, and it is why you have the conversations to answer once you reconnect. What to do Open Settings → Inboxes → the inbox. | How the number was connected | Where to fix it | |---|---| | Through the guided WhatsApp sign-up | the inbox's Configuration tab — reconnect and approve the permissions again | | With a token you pasted in yourself | Configuration — replace the token with a fresh one from your Meta app | Then open Account Health and confirm the number reports normally. See reconnect a WhatsApp number for the whole sequence, including what to check if reconnecting is refused. A worked example An administrator removes a colleague from the Meta business portfolio on a Thursday. The token that colleague had authorised stops working, and after the second refused send the dashboard banner appears and the administrators are emailed. They reconnect the inbox from Configuration, approve the permissions, and the queue of conversations that arrived during the outage is waiting in the inbox. Who can do this Administrators only. Agents see the banner and can keep reading, but Configuration and Account Health are not open to them — see roles and permissions. Limits - Nothing re-sends the messages that failed while the token was invalid. Retry each one, or send again. - Lynomia Chat cannot tell you which permission was lost. Meta reports a refusal, not a diff. - Deleting and recreating the inbox is not the fix and can release the number from your Meta app. Reconnect first. - A token you generated by hand will expire again. The guided sign-up is what avoids repeating this. Related - Reconnect a WhatsApp number - Nothing is arriving from WhatsApp - Connect a WhatsApp number - When WhatsApp does not work

Flagged, restricted, banned — what the number's status means

Open Settings → Inboxes → the inbox → Account Health. Near the top is the number's status, as Meta reports it. Six values are treated here as worth your attention, and Lynomia Chat writes a line to the operator log when a number moves into one of them so the change is not silent. | Status | What Meta means by it | Can you act? | |---|---|---| | Flagged | quality dropped far enough that Meta is watching the number. Messages still send | yes — the cause is message quality | | Restricted | the number has hit a limit Meta imposed. Sending is reduced or stopped | partly — it lifts as quality recovers | | Rate limited | too many messages too quickly for this number's tier | yes — slow down, and see messaging limits | | Banned | Meta has removed the number's ability to message | no, not from here. Appeal in WhatsApp Manager | | Disconnected | the number is no longer attached to a usable WhatsApp Business account | sometimes — see reconnect a number | | Deleted | the number has been removed at Meta | no. Connect a different number | The honest division Three of these are about what you send: Flagged, Restricted and Rate limited all come from quality and volume, and they improve when the messaging does. That is the part you control, and quality rating and messaging limits is the article about it. Three are about the number's standing at Meta: Banned, Disconnected and Deleted. Nothing in Lynomia Chat changes any of them. A ban is appealed in WhatsApp Manager, by the business that owns the number, and the outcome is Meta's. Saying this plainly matters, because the instinct on seeing Banned is to reconnect the inbox or recreate it. Neither helps, and recreating it can release the number from your Meta app — which makes reconnecting harder once the ban is lifted. What to do first 1. Read the status on Account Health rather than guessing from symptoms. Restricted and error 131042 both stop messages and have nothing to do with each other. 2. If the status is one of the first three, look at your recent campaigns: volume, audience size and whether people are blocking or reporting the messages. 3. If it is one of the last three, the work is at Meta. Note the date and what changed before it. Who can do this Administrators. Account Health is not available to agents, and the permission list for a custom role has no entry for inboxes — see roles and permissions. Limits - Lynomia Chat cannot change any status. All six are Meta's. - There is no alert when a status changes. The value is on Account Health; nobody is emailed. - The history is not kept in the product. Account Health shows the latest answer Meta gave. - A number can be Flagged and still send normally, which is why it is easy to miss until it becomes Restricted. Related - Quality rating and messaging limits - Reconnect a WhatsApp number - When WhatsApp does not work - WhatsApp campaigns

Quality rating and messaging limits

Account Health reports two numbers Meta keeps about your WhatsApp number: a quality rating and a messaging limit tier. They are related but not the same thing, and confusing them wastes effort. Quality rating Green, yellow or red. It is a rolling judgement based on how recipients react — blocking the number, reporting it, or simply never replying. It is not about your templates being approved, your server, or how many messages you send. Yellow and red are treated as risky here: Lynomia Chat records the transition in the operator log so a drop is visible after the fact rather than discovered later. | Rating | What it means in practice | |---|---| | Green | nothing to do | | Yellow | enough negative signal to be noticed. Still sending. This is the moment to act | | Red | sustained negative signal. A messaging limit cut usually follows | Messaging limit tier How many unique customers you may start a conversation with in a rolling 24 hours — not how many messages you may send. Replying inside the 24-hour window does not count against it. Tiers go up on their own when you send consistently at quality, and down when the rating is red. Hitting the ceiling shows up as Rate limited on the number's status — see what the number's status means. What actually improves both Only one thing, in the end: send messages people want. - Send to people who asked. An audience built from customers who opted in behaves completely differently from one built from every contact you have. - Send less, and less often. The commonest cause of a yellow rating is the same list receiving the same kind of promotion repeatedly. It is also what produces error 131049. - Make it obvious who you are in the first line. A message that reads as unexpected gets blocked. - Answer replies. A number that only broadcasts collects worse signal than one that holds conversations. What does not help: resubmitting templates, reconnecting the number, changing the display name, or sending the same campaign again to the people it failed for. A worked example A clinic's rating goes yellow a week after it starts sending a weekly offer to its whole contact list. It stops the weekly send, keeps appointment reminders — which are about one transaction and go to people expecting them — and sends nothing promotional for a fortnight. The rating returns to green and the tier is untouched, because it never reached red. Who can do this Administrators read Account Health and run campaigns. Agents can see neither. Limits - Neither number can be changed from here, or by support. Both are Meta's. - There is no history in Lynomia Chat. Account Health shows Meta's latest answer. - No alert fires when the rating drops or the tier is cut. - A tier increase is not something you can request in the product. - The rating is per number, so a second number does not inherit a good one — and splitting marketing onto a separate number to protect the main one is a decision to make deliberately, not a trick that removes the cap. Related - What the number's status means - Error 131049 - The WhatsApp 24-hour window - WhatsApp campaigns

The display name was not approved

Account Health reports the number's display name and whether Meta approved it. A refusal is the least serious thing on that page, and the easiest to misread. What it does and does not stop Messages keep sending. An unapproved display name does not block anything. What it changes is what the customer sees: your number instead of your business name. That is a real cost — an unknown number is more likely to be ignored or blocked, which feeds into quality rating — but it is not an outage, and nothing here needs reconnecting. Why a name is refused Meta's rule is that the display name must be the name customers know the business by. Refusals usually come from: - a name that does not match the business's own website or registration, - a generic word or phrase rather than a business name, - a name containing a URL, a phone number or a promotion, - a name that refers to WhatsApp or Meta. What to do The display name is changed in WhatsApp Manager, not in Lynomia Chat. Change it there, submit it, and Meta reviews it. Account Health will report the new state once Meta has answered. Do not reconnect the inbox, resubmit templates or recreate the number. None of those is connected to the name. Who can do this The person with access to WhatsApp Manager for that business. In Lynomia Chat, only an administrator can even see the current state, on Account Health. Limits - Lynomia Chat cannot change or submit a display name. It reports what Meta says. - There is no notification when a name is approved or refused. - A name change can take days and Meta gives no estimate. - A refused name does not expire. The number keeps showing as a number until a name is approved. Related - What the number's status means - Quality rating and messaging limits - Connect a WhatsApp number

Nothing is arriving from WhatsApp

Customers say they wrote and nothing is in Conversations. There are only a few causes, and Settings → Inboxes → the inbox → Account Health distinguishes them. The one to check first Webhook not configured, or a URL that does not match. WhatsApp delivers incoming messages by calling your installation; if Meta does not know where to call, or is calling somewhere else, nothing arrives and nothing fails visibly. Press Register Webhook on that tab. This is the commonest cause by a wide margin, and it is the one that produces exactly the symptom of total silence rather than partial trouble. The rest, in order | What you see | What it is | |---|---| | WhatsApp connection needs to be refreshed, or access token needs attention | the credential stopped being accepted. See error 190 and reconnect a number | | Status Banned, Disconnected or Deleted | the number's standing at Meta. See what the status means | | An incoming message that is there but empty | it arrived and WhatsApp would not hand it over. See error 131060 | | Health data is not available | Meta did not answer this request. Try again before concluding anything | | Everything looks healthy | the messages may be arriving in an inbox this agent is not a collaborator on — see set up an inbox | That last row is worth taking seriously before escalating. An agent sees only the inboxes they are a member of, so "nothing is arriving" and "nothing is arriving for me" look identical from an agent's screen. What an operator can check that you cannot A deployed installation has a read-only diagnostic an operator runs on the server. It reports whether Meta's calls are reaching the route, whether the background workers are processing them, what the queue depth is, and what the recent outbound failures actually said. If Account Health looks healthy and messages still are not appearing, that is the next step and it is the operator's, not yours. A worked example Messages stop on a Sunday. Account Health says Webhook not configured. The administrator presses Register Webhook, the warning clears, and a test message from their own phone appears in Conversations within seconds. The messages customers sent while the webhook was missing never arrive — WhatsApp had nowhere to deliver them — so the team answers what did arrive and reopens the rest with a template. Who can do this Administrators, for everything above. An agent can confirm the symptom and should escalate rather than wait. Limits - Messages sent while the webhook was missing are gone. There is no backfill and no replay. This is the single most important limit on this page. - There is no alert when incoming messages stop. Silence looks like a quiet day. - Registering the webhook does not fetch anything retrospectively. - Account Health reports Meta's answer at that moment, not a history. Related - Error 190 - Reconnect a WhatsApp number - What the number's status means - When WhatsApp does not work - Set up an inbox

Reconnect a WhatsApp number

A WhatsApp number needs reconnecting when its credential stopped being accepted — see error 190 for what causes that. The sequence matters, because the wrong first step can make the number harder to recover. The order 1. Settings → Inboxes → the inbox → Configuration. Reconnect from here. For a number connected through the guided sign-up this re-runs it; for a manually connected number this is where you replace the token. 2. Account Health. Confirm the number now reports normally, and that the webhook is registered. 3. Send one test message from your own phone to the number, and check it appears in Conversations. 4. Retry what failed. Nothing re-sends by itself. What the refusals during reconnection mean | What you see | What it means | |---|---| | Failed to exchange code for access token | the guided sign-up did not complete. Start it again; do not paste a token as a workaround | | The access token does not have the required permissions | the authorisation was approved without everything WhatsApp needs. Re-run it and approve all of it | | Failed to fetch phone number information | Meta accepted the credential but would not describe the number. Usually transient; try again | | Channel already exists for this phone number | the number is connected somewhere else on this installation — see the number is already connected | | Reauthorization is not supported for this type of WhatsApp channel | this is not a Cloud API number. A number connected through another provider is reconnected through that provider's settings | The two things not to do Do not delete the inbox. It does not reconnect anything, it loses the inbox's settings and collaborators, and it can release the number from your Meta app — which turns a five-minute reconnection into a support case. Do not connect the number a second time as a new inbox. A number can only be connected once across the whole installation, so this fails, and the failure message is easy to mistake for something else. A worked example An inbox shows the reauthorization banner on Monday morning. The administrator opens Configuration, reconnects through the guided flow, approves the permissions, and checks Account Health — the number reports normally and the webhook is registered. A test message arrives. They then go through Friday's three failed replies and press Retry on each. Total time, about four minutes. Who can do this Administrators only. Configuration and Account Health are not open to agents, and no custom role permission covers inboxes — see roles and permissions. Limits - Messages that failed while the number was disconnected are not re-sent. Retry each one. - Incoming messages during the outage were still stored, which is why there is a queue to work through. - Lynomia Chat cannot tell you which permission was missing. Meta reports a refusal, not a diff. - A hand-made token will expire again. The guided sign-up is what stops this recurring. Related - Error 190 - The number is already connected - Nothing is arriving from WhatsApp - Connect a WhatsApp number - WhatsApp Business coexistence

"Channel already exists for this phone number"

You are adding a WhatsApp number and it is refused: a channel already exists for this phone number. The refusal is exactly true and it is wider than your workspace. A WhatsApp number can be connected once across the whole installation, not once per account. So the number may be in use somewhere you cannot see. Why it works that way Incoming messages are delivered per number. If two inboxes claimed the same number, there would be no honest answer to the question of which conversation an arriving message belongs to. The uniqueness is what keeps that from happening. What to do If it is your own number, in your own workspace. Look for it in Settings → Inboxes — including inboxes you may have archived or forgotten. If it is there and broken, you want reconnect a WhatsApp number, not a second inbox. If you cannot find it. Then it is connected in another workspace on this installation. Only the operator can see that, so this is a support request: give them the number and ask where it is connected. They can see it; you cannot, and that is deliberate. If it was connected by a colleague who has left. Same answer. The inbox still exists and still owns the number; it needs to be found and either handed over or removed. What not to do Do not try the number in a different format, with or without a leading +, or with the country code written differently. The check is on the number, and working around it is not possible — the attempts only add noise to whatever the operator has to read later. Who can do this Administrators add inboxes. Finding a number connected in another workspace needs the operator of the installation. Limits - Lynomia Chat will not tell you which account holds the number. Naming another workspace to you would leak it; the refusal is deliberately plain. - Removing the other inbox is not something you can do unless it is in your own account. - Deleting an inbox to free a number can release the number from the Meta app, which is a second problem. Reconnecting is almost always what you actually want. Related - Reconnect a WhatsApp number - Connect a WhatsApp number - Set up an inbox

A contact information request was refused

Some WhatsApp customers reach you without a phone number — see business-scoped WhatsApp contacts for what that is. For those, Lynomia Chat can ask WhatsApp to request the number from the customer, and the customer chooses whether to share it. The action is unavailable more often than it is available, and the reason is always one of six. | Reason you see | What it means | Can you clear it? | |---|---|---| | Available only for WhatsApp Cloud inboxes | the conversation is on a different kind of WhatsApp connection | no, not for this inbox | | This contact already has a phone number | there is nothing to request | no, and nothing is wrong | | Can only be requested from a business-scoped WhatsApp user | this contact is not one of those, so the request does not apply | no | | Only within the 24-hour window | the customer last wrote more than 24 hours ago | yes — wait for them to write, or send a template | | An approved template with a Request contact info button is required | outside the window, the request has to travel inside a template that carries that button, and none is approved | yes — have one approved | | A request is already pending | you have asked and the customer has not answered | yes, by waiting | The two worth planning for Outside the window you need a template. The fourth and fifth rows are the same situation from two directions: inside the 24-hour window the request can be sent directly; outside it, it must be carried by an approved template with a Request contact info button. If you intend to do this routinely, get that template approved before you need it — see the template lifecycle. A pending request blocks another. Only one can be outstanding per contact at a time, which stops an agent asking twice and stops two agents asking in parallel. A failed request does not count as pending, so a genuine failure does not lock the contact out. Who can do this Any agent working the conversation can send a request where it is available. Getting the template approved is an administrator's job. Limits - The customer decides. They may refuse, and there is no appeal and no second mechanism. - You cannot cancel a pending request. It resolves when the customer answers or stops being pending. - Nothing tells you a request was refused by the customer as distinct from ignored. - A shared number cannot be requested twice in parallel. Related - Business-scoped WhatsApp contacts - The WhatsApp 24-hour window - The template lifecycle - Contacts

Business-scoped WhatsApp contacts, and what cannot be sent to them

Most WhatsApp customers arrive with a phone number. Some arrive with a business-scoped identifier instead — an id that identifies them to your business only, with no phone number attached. WhatsApp does this when the customer reaches you through certain entry points, and it is normal rather than broken. You can hold the whole conversation with such a contact. What you cannot do is anything that needs the number itself. The two refusals you will meet Authentication templates require a phone number. A one-time-passcode template is refused for a business-scoped contact, because the passcode's whole purpose is to prove control of a number that is not there. There is no workaround, and this is the right outcome: delivering a passcode to an identifier you cannot verify would be worse than refusing. The template's category could not be verified. Sending to a business-scoped contact requires knowing which category the template is, and the category is read from the inbox's synced template list. If the template is not in that list under that name and language, Lynomia Chat refuses rather than guess — a wrong guess here could send an authentication template to a contact that must not receive one. Clearing the second one is straightforward: open Settings → Templates, press Sync templates, and confirm the template appears with the name and language you are sending. See WhatsApp templates. Getting a phone number You can ask for one — WhatsApp puts the request to the customer and they decide. The conditions are in a contact information request was refused. Once a number is shared, the contact becomes an ordinary contact and these two refusals stop applying. Who can do this Any agent can send and will see the refusals. Syncing templates and getting a template approved are administrator work. Limits - You cannot convert a business-scoped contact yourself. Only the customer sharing their number does that. - Authentication templates stay refused for as long as there is no number. This is deliberate. - Merging such a contact with one that has a phone number does not retrospectively make earlier messages sendable. - The identifier is scoped to your business. It is not a WhatsApp account id you can use anywhere else. Related - A contact information request was refused - WhatsApp templates - The template lifecycle - Contacts

Finding the conversations where a message failed

A failure is shown on the message, inside the conversation: Failed to send, the explanation where Lynomia Chat recognises the code, WhatsApp's own words, and a Retry button where retrying could possibly work. That is precise and it is easy to walk past. A conversation containing a failed message looks like any other conversation in the list. Finding one again If you know the customer. Search for the contact and open the conversation. The failed message is in place, in the timeline, where it was. If you do not. Two places are worth looking: | Where | What it tells you | |---|---| | The campaign's own report, under Campaigns | which sends failed, for a campaign. See WhatsApp campaigns | | The operator's diagnostic, on the server | the recent failed outgoing messages on a WhatsApp inbox and what each refusal said | The second is the operator's, not yours, but it is the honest answer to "which messages failed on this number this week" and it is worth knowing it exists before you spend time reconstructing it by hand. Listing them Conversations → Filter → Message delivery → Equal to → Failed to send. The condition asks whether the conversation contains a message with that delivery status, so it finds the conversation however long ago the failure happened and wherever it sits in the thread. It combines with the other conditions, which is where it earns its keep: | Add this | To get | |---|---| | Status is Open | failures still waiting on somebody | | Inbox is your WhatsApp number | failures on that number only | | Assignee is you | your own | | Last activity is 7 days before | the ones that have gone quiet since | Save it as a folder. Once the filter is right, save it, and the queue is one click away from then on rather than something to rebuild. See work in the inbox. One honest note: a conversation whose failure was retried successfully still contains the original failed message, so it still matches. The filter answers "something failed here", not "something is still broken here" — open the conversation to tell the two apart. Two habits make the rest less costly: - Watch the composer, not just the message. Where the 24-hour window has closed, the composer is disabled before you type — that is the failure prevented rather than recorded. - Read a campaign's report after it finishes, rather than treating completed as delivered. Who can do this Any agent sees failures in the conversations they can open. A campaign's report is an administrator's. The server-side diagnostic is the operator's. Limits - No notification is raised when a message fails. The agent who sent it sees it; nobody else is told, so the filter is something somebody has to look at. - The filter does not distinguish a failure that was later retried from one that was not. - A failed message is not retried automatically, ever, by design — see error 131042 for why that matters. - Retry is withdrawn where a retry would simply repeat the refusal — see error 131049. - A failure older than a day cannot be retried from the conversation. Send again instead. Related - Error 131049 - Error 131042 - When WhatsApp does not work - WhatsApp campaigns - Work in the inbox