WhatsApp Error 133005: Resetting a Lost Two-Step PIN

Why does my number registration fail with WhatsApp error 133005?

Because the six-digit PIN your /register call sent does not match the two-step verification PIN currently set on that business phone number. Meta's entire description of the code is four words:

"Two-step verification PIN incorrect." (Meta - WhatsApp Cloud API error codes)

Every page that ranks for this code gets that much right. The interesting part is the remedy printed beside it:

"Verify that the two-step verification PIN included in the request is correct. To reset the PIN, disable two-step verification, then set a new PIN. See Two-step verification." (Meta - WhatsApp Cloud API error codes)

Follow that instruction and you find that the disable it recommends is not something your code can perform:

"Note that you cannot disable two-step verification using the API." (Meta - Business phone numbers)

So the remedy is real, and it is the long way round. The button exists, in WhatsApp Manager, and pressing it sends an email to your business portfolio's address that somebody then has to click. The same documentation describes a second route that takes one HTTP request, needs no email, and does not switch the feature off at all. Almost nothing written about 133005 describes either accurately.

The short version is that you do not need to disable two-step verification at all. You overwrite the PIN, and overwriting it through the API does not require knowing the old one.

• Why does my number registration fail with WhatsApp error 133005?
• Can you turn two-step verification off at all?
• Why is WhatsApp Manager stricter than the API here?
• What do you actually type to set a new PIN?
• How do 133005, 133008 and 133009 differ from each other?
• Which registration errors are in the same family as 133005?
• How many registration attempts does a wrong PIN cost you?
• Why do so many pages say 133005 returns HTTP 503?
• Is there a seven-day wait before you can reset the PIN?
• What should your platform do about the PIN on your behalf?
• What is the safe order of operations on a lost PIN?

Can you turn two-step verification off at all?

Yes, in WhatsApp Manager. No, not over the API. Meta's current business phone numbers documentation states both halves, a few lines apart. The manual route reads:

"To disable two-step verification using WhatsApp Manager, follow the steps for changing your PIN, but click the Turn off two-step verification button as the final step instead. An email with a link will be sent to the email address associated with your business portfolio. Use the link to disable two-step verification." (Meta - Business phone numbers)

The older Cloud API reference page, still live and still the URL most vendor articles link to, carries only the API half of that:

"There is no endpoint to disable two-step verification." (Meta - Two-step verification)

That is where a good deal of the confusion starts. A reader sent to the legacy URL reads a flat "no endpoint", sees no description of the control that does exist, and concludes the remedy printed beside 133005 cannot be performed at all.

Why is WhatsApp Manager stricter than the API here?

Because the interface asks for the thing you have lost and the API does not. Meta says so in one sentence:

"You will need your current PIN to change your PIN via WhatsApp Manager." (Meta - Business phone numbers)

The steps it then gives are for someone who still has the PIN:

"1. Navigate to WhatsApp Manager > Account tools > Phone numbers. 2. Select your business phone number. 3. Click the Two-step verification tab. 4. Click the Change PIN button and complete the flow." (Meta - Business phone numbers)

So in the interface a forgotten PIN forces you onto the disable-and-email path, because Change PIN will not accept you without the old value. Over the API the same problem is a single write. The interface is the more restrictive of the two surfaces, which is the opposite of what most people assume.

Checked against Meta's documentation on 11 September 2026.

What do you actually type to set a new PIN?

This is where most writing on 133005 goes wrong, and the mistake is an understandable one. The documentation page is titled "Two-step verification", so it is natural to assume a matching /two_step_verification edge exists. It does not. Meta's instruction is:

"Use the WhatsApp Business Phone Number API to set a new PIN." (Meta - Business phone numbers)

That means POSTing to the bare phone number node, the same id you send messages from, with nothing appended to it:

curl -X  POST \
 'https://graph.facebook.com/v25.0/FROM_PHONE_NUMBER_ID' \
 -H 'Authorization: Bearer ACCESS_TOKEN' \
 -H 'Content-Type: application/json' \
 -d '{"pin" : "6_DIGIT_PIN"}'

That is Meta's own example, copied from the reference. The single parameter is described as:

"A 6-digit PIN you wish to use for two-step verification." (Meta - Two-step verification)

Note what is absent from the body. There is no field for the current PIN, no old_pin, no confirmation challenge, no email. The authorisation is the access token's ability to write to that phone number, and nothing else.

Then register, passing the value you just set:

curl 'https://graph.facebook.com/v25.0/106540352242922/register' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer EAAJB...' \
-d '{
  "messaging_product": "whatsapp",
  "pin": "212834"
}'

Meta's registration page covers both situations in one parameter description, and buries the sentence the 133005 remedy should have carried:

"If your verified business phone number already has two-step verification enabled, set this value to your number's 6-digit two-step verification PIN. If you cannot recall your PIN, you can change it. See Two-step verification. If your verified business phone number does not have two-step verification enabled, set this value to a 6-digit number. This will be the newly verified business phone number's two-step verification PIN." (Meta - Register a business phone number)

"If you cannot recall your PIN, you can change it" is the answer to 133005, and it sits on a page the error's own remedy does not link to.

How do 133005, 133008 and 133009 differ from each other?

Three codes, one subject, and they arrive in that order if you keep guessing. Meta's details strings, word for word:

133005  Two-step verification PIN incorrect.
133008  Too many two-step verification PIN guesses for this phone number.
133009  Two-step verification PIN was entered too quickly.

133005 is one wrong answer. 133008 is Meta declining to hear any more answers from that number for a while. 133009 is a velocity check rather than a count, which is why a script retrying immediately can trip it well before it has spent its guesses.

Those are the reference's own three columns, and the middle one matters more than its label suggests: it is the details value carried in the response body, which is exactly the field the last two rows tell you to read. Now look at what is missing from the right-hand column: a number. Meta publishes no lockout duration for 133008 and none for 133009. Both remedies point at a value your own failed request handed you. Read it and honour it. Do not take a figure from an article, including this one.

Checked against Meta's documentation on 11 September 2026.

Which registration errors are in the same family as 133005?

They sit together under the "Other errors" heading of the error codes reference, and two of them are commonly mistaken for a PIN problem when they are nothing of the kind.

Code 133010 belongs in the same neighbourhood and reads in the opposite direction to everything above: "Phone number not registered on the WhatsApp Business Platform." If you are seeing that one, the PIN is not your problem at all, because nothing has been registered yet to have a PIN attached.

Five minutes is the only numeric wait Meta publishes anywhere in that table, or beside the three PIN codes above it. There is one other published figure in this area, in the "Throttling errors" section of the same reference, and it is the expensive one. The next section is about that.

One more code borders this set without belonging to it. Error 131031 can mean an incorrect two-step PIN or an account-level policy restriction, and the two have completely different costs. Rule out the PIN first, because it is the cheaper explanation, and see what actually gets a WhatsApp Business account restricted for the other reading.

How many registration attempts does a wrong PIN cost you?

One each, out of ten, and this is the real scarce resource in a lost-PIN incident. Meta's registration page states the limit and the consequence in the same paragraph:

"Requests to the registration endpoint are limited to 10 requests per business number in a 72-hour moving window. When you make a registration request, the API checks how many registration requests you have made to register that number in the last 72 hours. 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." (Meta - Register a business phone number)

That paragraph contains two different models of the same limit and they pull against each other. A "moving window" implies the budget refills gradually as old attempts age out of the last 72 hours. The operative clause is flat: once you trip it, "the API prevents the number from being registered for the next 72 hours". Plan against the harsher reading, because it is the one written in the sentence describing what actually happens.

The code appears in the error codes reference too, under "Throttling errors" rather than beside its PIN-shaped siblings:

"Registration or Deregistration failed because there were too many attempts for this phone number in a short period of time" (Meta - WhatsApp Cloud API error codes)

with the resolution:

"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)

Deregistration carries its own separate allowance of the same size, with the same code returned when it is exhausted, per the same registration page. So the two budgets are:

The asymmetry that matters: setting a new PIN spends neither budget, because it is an ordinary write to the phone number node rather than a registration request. Guessing spends one every single time. Overwrite first, register once.

Why do so many pages say 133005 returns HTTP 503?

Because somebody wrote it down and everybody copied it. The table that carries 133005 has three columns: the code, the details string, and Meta's possible reasons and solutions. There is no HTTP status column on it, so Meta publishes no status for 133005 or for any of its neighbours. Statuses do appear elsewhere in the same reference, in the Marketing Messages API section, which is a different surface. A page asserting "133005 is a 503" is filling in a field the source does not have.

This is not pedantry. If your error handling branches on the HTTP status line rather than on the numeric code inside the response body, it is branching on something Meta never committed to. Every row Meta publishes puts the code and the details string at the centre, and that is where your handling belongs.

Is there a seven-day wait before you can reset the PIN?

Not according to anything on Meta's developer documentation. The error codes reference and the business phone numbers documentation were both read on 11 September 2026, and neither publishes a seven-day wait, nor any lockout duration for the PIN codes at all.

There is an email step in this area, which is probably where some of the confusion lands, and it carries no published delay: turning two-step verification off in WhatsApp Manager sends a link to your business portfolio's address, and Meta describes no waiting period attached to it. The only durations documented anywhere here are 133015's five minutes, the 72 hours behind 133016, and the unspecified details value that 133008 and 133009 tell you to read.

The cost of believing the seven-day figure is high and entirely avoidable: a business that thinks it must wait a week leaves a number unregistered and silent for a week, when the documented fix is two calls and no waiting.

What should your platform do about the PIN on your behalf?

Very little, and that is the correct answer rather than a limitation. The PIN belongs to the number, the number belongs to the customer's WhatsApp Business Account, and a platform that stores customers' PINs has taken on a liability in exchange for saving one field.

Where a platform can earn its place is in what it refuses to do. WabaCRM does not retry /register after a 133005: the error is surfaced to the customer once and the attempt stops, because a retry loop can spend a ten-request budget in under a minute and leave the number blocked for three days. How the number arrived matters too. A number connected with manual Cloud API credentials needs the PIN at registration; a coexistence connection never calls the registration endpoint at all, because the number is already registered and running in the WhatsApp Business app, which removes this entire class of failure. If you are moving a number between tools, the PIN is one of several things worth settling before the cutover, and what carries over when you switch providers covers the rest.

What is the safe order of operations on a lost PIN?

Five steps, in this order, with no guessing anywhere in them.

1. Stop calling /register. Every attempt with a PIN you are not sure of costs one of ten, and the tenth costs you 72 hours. If you have already seen 133008 or 133009, read the details value in that response and wait exactly that long.
2. Set a new PIN by POSTing {"pin": "<six digits>"} to the phone number node. No old value is required, and this request is not a registration request, so it does not touch either 72-hour budget. Do not open WhatsApp Manager for this: Change PIN there will ask you for the value you have lost.
3. Record the new PIN somewhere the whole team can reach, not in one person's password manager. The commonest cause of this error is not an attack; it is the person who set the PIN having left.
4. Call /register once, with messaging_product set to whatsapp and the PIN you just set. One attempt, not a loop.
5. If it still fails, read the code rather than the status. 133006 means the number was never verified, 133000 means a previous deregistration did not finish, 133015 means the number was deleted minutes ago. None of those is fixed by another PIN.

The reason this order is worth writing down is that the documented remedy sends you into a second interface and an inbox you may not control, to switch off a security feature you wanted, when the thing you needed was one request.

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