A business phone number can show a green tick in WhatsApp Manager, pass ownership verification, sit happily inside your WhatsApp Business Account — and still be completely invisible to the API. Meta’s own documentation states it plainly: adding and verifying a number does not register it for Cloud API use.
That single gap sits behind a large share of “we finished setup but nothing sends” tickets. What follows is what the registration layer actually is, which numbers can never pass it, and the two limits that make a careless attempt expensive rather than merely annoying.
Three different things people all call “adding the number”
Meta splits getting a number ready into three distinct operations. Most teams do the first two in the browser, see a verified status, and assume they are finished.
- Add the number to the WhatsApp Business AccountDone in WhatsApp Manager, Meta Business Suite, the App Dashboard, or through a Solution Partner’s Embedded Signup link. This only associates the number with the account.
- Verify ownership of the numberA code is delivered by SMS or voice call and submitted back. This proves you control the line. It still does not make the number usable by the API.
- Register the number for Cloud APIMeta is explicit that this step exists only as an API call: a number cannot be registered through WhatsApp Manager or the App Dashboard. This is the step that is skipped.
The sentence most setups never read
Meta’s Business phone numbers documentation notes that the browser-based methods add a phone number to your WhatsApp Business account and verify your ownership, but they do not register the number for Cloud API use — registration requires calling the register endpoint.
Until that call succeeds, the number will not send or receive anything, no matter how correct the rest of your Cloud API setup is.
Some numbers were never going to qualify
Before any of this, the line itself has to be eligible. Meta’s published requirements are short but they eliminate a surprising number of the phone numbers businesses actually want to use.
Already live on WhatsApp
A number already in use with WhatsApp cannot be registered unless it is deleted from WhatsApp first. If the number is banned on WhatsApp, it must be unbanned through the appeal process before registration is even possible.
Short codes
An eligible number must have a country and area code. Short codes are not supported at all — there is no workaround for this one.
VoIP, landline and toll-free
Meta rates these as not recommended for receiving the code by SMS, though voice delivery is rated standard. They are not banned, but the default SMS route is the one most likely to silently fail on these line types.
Numbers behind an IVR
Meta states that a WhatsApp registration call cannot navigate an IVR. Such numbers can be registered only if the call is redirected to a real person or mailbox; numbers unable to receive the registration call are not supported.
Pager and M2M lines
Pager numbers are listed as not supported for either delivery method. Machine-to-machine and IoT SIMs are rated not recommended for both SMS and voice.
International reception disabled
The verification code originates internationally. Carrier-level blocks on inbound international SMS or calls are a common and completely invisible cause of a code that never arrives.
The 72-hour window you can burn through in an afternoon
This is the part that turns a bad setup day into a bad setup week. Registration attempts are metered, and the meter does not reset when you fix the underlying problem.
Meta’s documentation is direct about the consequence: once ten requests have been made inside the window, the API returns error 133016 and prevents the number from being registered for the next 72 hours. Deregistration carries an identical cap.
Ten attempts sounds generous. It is not, if a team is guessing at the PIN, guessing at the permissions on the access token, or retrying blindly because a code never arrived. A separate trap sits one step earlier: calling the request-code endpoint on a number that is already verified returns HTTP 400 with error 136024, which reads like a failure and invites exactly the kind of retry that eats the budget.
The PIN with no off switch on the API side
Registration requires a six-digit two-step verification PIN. If the number already has two-step verification enabled you must supply the existing PIN; if it does not, the value you send becomes the PIN from that moment forward.
This is a one-way door through the API
Meta states there is no endpoint to disable two-step verification. Turning it off is a manual WhatsApp Manager operation that sends a link to the email address associated with the business portfolio.
The same PIN is required later to change the PIN and to delete the number from the platform. A PIN set carelessly during a rushed first registration, by a contractor who has since left, becomes a genuine operational problem months later.
Caps and other one-way doors
- Portfolio number cap. New business portfolios start capped at two registered business phone numbers. Meta raises this to 20 automatically once the business becomes verified or a messaging limit of 2,000 is reached — not on request.
- Data localization. If local storage is enabled at registration, it cannot be disabled or changed directly. Changing it means deregistering the number and registering again, which consumes attempts from the same 72-hour budget.
- Deletion is restricted. Only business portfolio admins can delete a number, deletion is not available through the API at all, and a number that has sent paid messages within the last 30 days cannot be deleted until that window passes.
- Display name status can block registration outright. A number whose display name status is EXPIRED or NONE cannot be used to register the number for API use. Separately, after an approved display name change you must re-register — and re-registering before approval has no effect. See why display names get rejected.
- Registered numbers leave WhatsApp Messenger. A registered number can still take ordinary calls and texts, but it cannot be used with consumer WhatsApp. If the business genuinely needs both, that is a coexistence decision that has to be made before registration, not after.
What “done” actually looks like
A number is only finished when the platform agrees it is. Meta’s stated bar is that a business phone number must have a status of connected in order to send and receive messages via the API. Anything else — verified, added, pending, approved display name — is an intermediate state that will not move a single message.
The sequence that gets there cleanly is not complicated, but it is unforgiving: the right line type, an eligible and un-banned number, ownership verification through a delivery method the carrier will actually complete, an access token carrying the correct permissions, a deliberately chosen and recorded PIN, a localization decision made once, and the register call issued in the correct order — all inside a ten-attempt budget.
Where this goes wrong in practice
Almost none of the failures here announce themselves as failures. A code that never arrives looks like a carrier delay. Error 133016 looks like a temporary outage. A number sitting verified but unregistered looks finished. Teams commonly spend days on webhooks and templates before discovering the number underneath was never registered at all.
Getting it right the first time is largely about sequencing and about not spending attempts on guesses — which is what number setup and WhatsApp Business API approval support is for: reviewing eligibility before anything is submitted, choosing the delivery and localization path deliberately, and keeping the registration budget intact.