131047, 131051 and 133010: what the Cloud API means when it rejects your message
Three codes that show up early in any WhatsApp integration, and whose documented names point at the wrong place. One of them blames the recipient when the problem is the sender.
CCX EngineeringPlatform · Engineering · Aug 22, 2026 · 8 min read
What you'll take away
- How to tell the two window errors apart — and why only one is your fault
- Why 133010 is almost never about the account you're looking at
- The diagnostic that closes the case in a minute instead of an afternoon
131047 — re-engagement outside the window
It means you tried to send a free-form message after the 24-hour window closed. It's the most common error on this list and the easiest to understand: outside the window, approved templates only.
What confuses people is seeing it while the window looks open. In that case the problem is almost never the rule — it's your arithmetic. If you anchored the window to the time you processed the webhook instead of the timestamp inside it, any late redelivery from Meta inflates your window and 131047 becomes a mystery. We wrote a whole post on that detail, because it alone explains most cases.
131051 — the type the Cloud API can't represent
This one isn't a send error: it arrives on the INBOUND event. It appears when a customer sends something the Cloud API can't hand you in structured form, and the message arrives typed unsupported.
The trap is treating it like any other message. It does not open the service window. If your code records a window off the back of it, you end up with a conversation your system believes is open and Meta believes is closed — and the next free-form send comes back as 131047. The two errors are the same bug seen from two angles.
The correct handling is to record the message in the thread so the agent knows something arrived, without opening a window, firing automation or waking the AI.
133010 — the error whose name lies
Meta's message is “Account not registered”, which sounds like a problem with the recipient's account. It isn't. It means the phone_number_id used to send that particular conversation isn't registered with the Cloud API.
The detail that eats whole afternoons: it isn't necessarily the number you're looking at on screen. An organisation can hold two records of the same phone — one active, one a migration leftover marked disconnected. Imported conversations stay bound to the old record. The result: the same template delivers on one conversation and fails on another, in the same minute, with every indicator in the UI green.
It gets worse because most number screens hide disconnected records. The guilty sender is invisible in exactly the interface where you went looking.
The diagnostic that cuts the path short
Before investigating token, tier, balance or registration, compare the phone_number_id of a message that failed against one that went through. If they differ, you have a ghost record and the rest of the investigation is wasted time. If they match, then registration and token are worth a look.
Two things mislead during that check: the “connected” badge in your number list is usually a field in your own database rather than a call to Meta; and health endpoints sometimes fall back to a silent local mode when Meta fails, returning green without having asked anyone.