WhatsApp error 133010: phone number not registered

Disclaimer: Registration flow steps evolve with each Cloud API version. Cross-check the endpoint reference before scripting a registration.

What 133010 means, precisely

Meta's Cloud API refused your send with code 133010 because the sending phone number has no valid registration record. In Meta's data model, a phone number attached to a WhatsApp Business Account (WABA) has a lifecycle:

1. Added — the number is associated with the WABA.
2. Verified — Meta confirmed ownership via OTP.
3. Registered — you posted your 6-digit two-factor PIN via the register endpoint.
4. Connected — messaging is now allowed.

133010 means the number is not in "Connected" state. Sends are blocked until registration completes.

Why registration can lapse

Registration is not permanent. It can be invalidated by:

• Migrating the number to a different WABA (common when moving BSPs).
• Disabling and re-enabling two-factor authentication.
• Meta forcing re-registration after a security event.
• The number being briefly used on the WhatsApp Business app (which deregisters it from the API).
• Extended inactivity — some markets see registration expire after long silence.

How to register step by step

1. In Meta Business Manager → WhatsApp Accounts → your WABA, confirm the phone number is Added and Verified.
2. Set a two-factor verification PIN via POST /{phone-number-id} with the pin field. Choose a 6-digit PIN you can retrieve later.
3. Register the number: POST /{phone-number-id}/register with { "messaging_product": "whatsapp", "pin": "123456" }.
4. Wait for the 200 response and verify status via GET /{phone-number-id} — the status should read CONNECTED.
5. Send a test template. 133010 should be gone.

Registration error cousins

Code	Root cause	Fix
133010	Not registered	Run register endpoint
133005	Wrong PIN	Reset PIN and retry
133006	Too many attempts	Wait 12-24 hours
133008	Number already registered to another WABA	Deregister from old WABA first
133009	Verification code required	Verify via OTP first

The migration scenario: moving a number between BSPs

This is where most Indian businesses hit 133010 unexpectedly. You've been happily sending on BSP A for a year. You decide to migrate to BSP B. The steps:

1. Deregister the number from BSP A's WABA using POST /{phone-number-id}/deregister.
2. Add the number to BSP B's WABA via Business Manager.
3. Verify ownership (OTP to your registered contact).
4. Register with a new PIN under BSP B.
5. Only then can you send.

Every hour spent between step 1 and step 5 is downtime. Plan the switch off-hours and rehearse the exact API calls. For a full migration guide see how to migrate BSPs without downtime.

Two-factor PIN management

The 6-digit PIN is Meta's protection against unauthorised registration. If you lose it, you must reset it — during which Meta will require the number owner to be reachable. In production:

• Store the PIN in a secrets manager, never in code or config files.
• Restrict access to two named engineers plus your BSP contact.
• Rotate whenever an engineer leaves the team.

Detecting drift before 133010 fires

Add a lightweight health check that runs every 15 minutes:

GET https://graph.facebook.com/v22.0/{phone-number-id}?fields=status,name_status,quality_rating

Alert if status flips from CONNECTED to anything else. You'll catch registration lapses before the first customer send fails.

Six practices that prevent 133010 in production

1. Automate registration as part of onboarding — never rely on manual dashboard steps.
2. Store PINs in a secrets manager and expose a reset workflow to on-call.
3. Health-check phone status every 15 minutes and alert on any state change.
4. Document the deregister-migrate-register flow before migrating BSPs.
5. Never use the WhatsApp Business app on a phone number that's also on Cloud API.
6. Treat 133010 as a P1 incident — every minute of 133010 is a minute of dropped OTPs, order updates and appointment reminders.

What 133010 is not

• Not a ban. Bans return 368 or 131031, not 133010.
• Not a template problem. Template errors are 132xxx.
• Not a rate limit issue. Rate limit errors are 130429 or 4.
• Not a quality rating issue. Quality changes show on the phone-status object, not as 133010.

How ChatShree handles registration

ChatShree automates the entire onboarding flow: number added, verified, PIN set and stored, and registration completed — all in one guided setup. Our platform runs continuous phone-status health checks and pages our on-call within 5 minutes of any state change so 133010 never surprises a live campaign. See how the team operates and how our BSP relationships accelerate migrations.

Closing thoughts

133010 is a lifecycle error, not a runtime one. Treat phone-number registration as infrastructure — automated, monitored, and owned by an on-call engineer, not a marketing manager clicking buttons in Business Manager. Once registration is invisible to your ops team, 133010 disappears from your incident reports for good.