WhatsApp Errors 131045 and 133016: the /register Trap

What does WhatsApp error 131045 mean?

Error 131045 means the business phone number you are sending from is not registered with Cloud API, and the fix is one API call. Meta's error code reference describes it as "Message failed to send due to a phone number registration error" and gives the whole solution in one sentence: "Register the phone number before trying again." (Meta — WhatsApp Cloud API error codes)

That makes it one of the cheapest errors on the whole list to resolve: a single POST /{phone-number-id}/register carrying the number's six-digit two-step verification PIN, and the number sends again. It is also, by the same mechanics, one of the easiest to convert into a three-day outage. Registration attempts are budgeted — ten per number per 72 hours — and the moment anything in your stack retries a failing register call in a loop, the budget is gone and error 133016 blocks the number from being registered at all for the next 72 hours. A one-request fix becomes a weekend of silence.

This article covers both codes together because they are two ends of the same rope: 131045 is the reason you call the register endpoint, and 133016 is what happens when you call it without discipline.

• What does WhatsApp error 131045 mean?
• Is a missing certificate the real cause of 131045?
• What does the register call actually need?
• What does error 133016 actually tell you?
• How does the 72-hour moving window work?
• How does a retry loop convert 131045 into a 72-hour outage?
• What should you check while the number is blocked?
• Why should a coexistence number never call register?
• How do 131045, 133016 and 133005 fit together?
• What is the safe operating rule for the register endpoint?

Is a missing certificate the real cause of 131045?

No, and this is the myth worth clearing first, because it is what the top-ranking pages for this error tell you to chase. Several vendor helpdesks explain 131045 as an "incorrect certificate" and send you looking for a certificate to download, upload or renew.

The word does not appear in Meta's Cloud API material for this error. We checked the error code reference — the entry for 131045 says "registration error" and nothing about a certificate, and the word "certificate" appears nowhere on the page. We checked the registration documentation the error's own solution links to — no certificate there either. The only inputs Cloud API registration takes are the phone number id in the path and a PIN in the body.

Certificate-based registration belonged to the earlier self-hosted era of this platform, and that era is over. Meta's own On-Premises page states that "The final supported version of the On-Premise API client expired on October 23, 2025" and that "On-Premises API can't be used to send messages to WhatsApp users anymore" (Meta — On-Premises API). The same page notes that business phone numbers "can only be registered for use with Cloud API". There is no certificate step left to perform, which is exactly why the hunt never ends: the artefact being hunted does not exist on the API you are using.

The cost of the myth is not just wasted hours. A developer who cannot find the certificate eventually starts retrying the register call to "see if it clears", and every one of those retries spends an attempt from the budget described below.

What does the register call actually need?

Two things: the phone number id, and a PIN. Meta's registration documentation opens with the requirement itself — "To use your business phone number with Cloud API you must register it" — and describes the pin parameter in two halves. If the number already has two-step verification enabled, "set this value to your number's 6-digit two-step verification PIN"; if it does not, "set this value to a 6-digit number", which becomes the number's two-step verification PIN from then on. (Meta — Registration)

POST /{phone-number-id}/register
{
  "messaging_product": "whatsapp",
  "pin": "123456"
}

The PIN is where most register calls die. A wrong value returns error 133005, Two-step verification PIN incorrect, and that failure repeats identically for as long as the PIN stays wrong — the mechanics of recovering a lost PIN without spending attempts are covered in our piece on error 133005 and the two-step verification PIN, including the API route that sets a new PIN without knowing the old one.

The same documentation also answers when the call is needed: when you first implement the API against a number, and again after certain changes — following an approved display name change, Meta's instruction is "After approval, re-register your phone number." Registration is an event tied to those occasions, not a keep-alive to be called on a schedule.

What does error 133016 actually tell you?

That the register endpoint has been called too many times, and that the door is now shut. Meta's error reference gives the detail as "Registration or Deregistration failed because there were too many attempts for this phone number in a short period of time" and the solution as "The business phone number is being blocked because it has reached its registration/deregistration attempt limit. Try again once the number is unblocked." (Meta — WhatsApp Cloud API error codes)

The vague "short period of time" has exact numbers behind it on the registration reference:

"Requests to the registration endpoint are limited to 10 requests per business number in a 72-hour moving window." (Meta — Registration)

and the consequence of exceeding it is spelled out on the same page: if you have already made 10 requests, "the API will return error code 133016, and the API prevents the number from being registered for the next 72 hours." Deregistration carries its own identically worded limit — ten requests, the same moving window, the same 72-hour block on deregistering.

Notice what the limit counts: requests. Not failures, not errors — requests. A successful registration spends an attempt exactly as a failed one does, which is why re-registering "just to be safe" from a deploy script is a quiet way to arrive at the block with nothing to show for it.

How does the 72-hour moving window work?

It moves. This is not a counter that resets at midnight or on Monday; it is a trailing 72-hour period, so at any moment the question is how many register requests this number has made in the preceding 72 hours. An attempt made on Tuesday morning stops counting against you Friday morning, not at the start of some calendar period.

The practical consequence is that attempts "come back" one at a time, each 72 hours after it was spent, rather than all at once. If a loop fired nine attempts in ten minutes on Tuesday, you do not get a fresh budget of ten on Wednesday — you get your first attempt back roughly 72 hours after the first of the nine was made. Budgeting around a moving window means treating every attempt as taking three days to earn back.

There is a second thing worth saying about the window precisely because Meta does not say it: nothing on either the error entry or the registration reference states whether requests made during an active block count against the window that follows it. A widely repeated vendor claim says that every retry during the block extends the lock. That claim appears on neither of the two Meta pages that define this limit — we checked both on 25 September 2026 — and we will not repeat it as fact. But the absence cuts both ways: Meta also never says blocked-period requests are free. The only behaviour that is safe under every reading is to stop calling the endpoint entirely once 133016 arrives.

How does a retry loop convert 131045 into a 72-hour outage?

Through the interaction of two properties: register failures are deterministic, and retry infrastructure is not built for deterministic failures.

The commonest way a register call fails is 133005 — the two-step PIN is wrong. A wrong PIN does not become right on the fifth attempt. But the call sits inside a send pipeline, and send pipelines are full of machinery that retries: a queued job with a retry policy, a cron that reconciles "unregistered" numbers every few minutes, an integration that re-runs setup whenever a send returns 131045. Each of those loops was written for transient failures, and each will happily make ten identical register requests in well under an hour. The eleventh answers 133016, and now the number cannot be registered at all — which means, for a number that genuinely needed registering, it cannot send — for three days.

In WabaCRM's own production, the rule is absolute: the platform never auto-retries a register call. When Meta answers 133005, the error is surfaced to the customer once and the flow stops, because we have costed the alternative — ten attempts inside 72 hours gets the number blocked for exactly the three days the limit describes. The retry mechanism for a wrong PIN is a human who knows the right PIN, not a queue.

If you are auditing your own stack for this, look for anything that calls the register endpoint from inside error handling. Registration belongs in a deliberate, human-initiated flow with the failure shown on screen; it does not belong in a catch block.

What should you check while the number is blocked?

The block itself has no lever — Meta's remedy is to wait for it to lift — so the useful work during those 72 hours is making sure the next register call is the last one needed.

Confirm the PIN first, since a wrong PIN is what usually started the loop. The 133005 post covers setting a fresh PIN through the API without the old value, which you can prepare now and execute after the block lifts. Then confirm the number's state in WhatsApp Manager: that it still exists on the WhatsApp Business Account you think it does, that its display name is not sitting in a pending change, and that no migration is in flight — a number mid-move between providers fails registration for an entirely different family of reasons under error 2388103, and no amount of PIN-checking fixes those.

This is also the argument for reading a number's health from Meta rather than inferring it. WabaCRM's numbers screen shows Meta's own health check verbatim on the number's card, because the honest answer to "why is this number not working" is whatever Meta currently reports about it — and acting on that report is a decision, not something a background job should do by reflex. A dashboard that says connected while nothing arrives is its own separate problem with its own checklist.

Why should a coexistence number never call register?

Because it is already registered, and every register call it makes spends budget the number never needed to spend. A number connected through WhatsApp coexistence stays live in the WhatsApp Business app on the owner's phone and mirrors to Cloud API; the registration that makes it sendable happened on the handset, as part of Meta's own onboarding, before your platform ever saw the number.

WabaCRM skips the register endpoint entirely for coexistence numbers for this reason. A platform that treats every new number identically — connect, then register — is making a call that does nothing useful on the happy path and, on the unhappy path, walks a coexistence number toward the same ten-attempt limit as everyone else. Ten pointless calls and the number is blocked from an operation it never required, with an error message about "registration attempts" that will make no sense to anyone reading the logs, because nobody remembers asking for the number to be registered.

The general rule underneath: whether a number needs /register is a property of how it was connected, and your code should know which path each number took rather than applying one ritual to all of them.

How do 131045, 133016 and 133005 fit together?

They are three points on one path: the reason to register, the failure inside the call, and the penalty for repeating it. Meta's descriptions, all read from the error code reference on 25 September 2026:

Read as a sequence: 131045 tells you to make the call, 133005 tells you the call's input was wrong, and 133016 tells you that you stopped listening to 133005. The middle row is the hinge — a stack that treats 133005 as terminal never sees 133016, because the loop that manufactures the block never runs.

What is the safe operating rule for the register endpoint?

Call it deliberately, at most once per human decision, and never from automation that owns a retry policy. Everything in this article compresses into four lines:

1. 131045 means register — once. The number is unregistered; one call with the right PIN ends it.
2. A failed register call is terminal, not transient. Surface it to a person. The commonest failure, a wrong PIN, fails identically forever.
3. Every request spends budget, success included. Ten per number per 72 trailing hours, register and deregister each with their own identically worded limit.
4. After 133016, do nothing. Meta publishes no early release and does not say blocked-period calls are free, so the only safe count of register requests during a block is zero.

The register endpoint is unusual in the Cloud API for how little it forgives: most of the platform's limits throttle you and recover in minutes, while this one blocks the number itself for three days and tells you to wait. Treat it with the respect a ten-shot magazine deserves.

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