WhatsApp error 463 and the reachout timelock, explained

WhatsApp error 463 is what a library such as Baileys or WAHA gets back when WhatsApp refuses to send a message because the account is under a reachout timelock: a temporary restriction on starting chats with people it has not talked to before. Chats that already exist keep working, and the restriction ends on its own. WhatsApp describes the restriction but never mentions the code.

What does error 463 look like in your logs?

Error 463 appears under different names depending on the library. whatsmeow and the GOWS engine of WAHA return server returned error 463. Baileys receives a message ack with error='463' and writes messageStubParameters: ["463"]. Evolution API, which wraps Baileys, often shows nothing except a message stuck in PENDING after the HTTP call succeeded, so the code only appears with LOG_BAILEYS=trace, as one user reported in the Baileys investigation thread.

The first public reports we found date from 12 February 2026 (whatsmeow issue 1074). The Baileys maintainers opened their investigation on 25 March 2026, and WAHA’s GOWS report followed on 31 March 2026. It was still open on 19 October 2026.

What does WhatsApp itself confirm?

WhatsApp’s help page About restricted accounts confirms the behavior without naming the error. An account can see the in-app message “Your account is restricted right now” or a warning that it may be restricted soon. The page says:

• The restriction ends automatically after a set time, and WhatsApp sends a notification when it does.
• To see the time left, tap New Chat and pick a contact you have never chatted with.
• The cause is recent activity that may show signs of spam, automated or bulk messaging.
• You can still communicate with contacts and groups you have exchanged chats or calls with.
• You cannot start chats or calls with new contacts, create groups, add members to groups or use linked devices, and you may be logged out of some companion devices.

A second page, How to use WhatsApp responsibly, tells people to message only those who contacted them first or asked to be contacted. It adds that WhatsApp uses machine learning and user reports to detect unwanted automated messages.

WhatsApp does not publish the code 463, the word “timelock”, thresholds or durations. Meta’s Cloud API error reference does not list 463 either.

What have developers found out?

Developers matched 463 to the restriction by reading WhatsApp Web’s own code. This is well-sourced reverse engineering, not documentation. The main findings:

• The name. A Baileys maintainer found NackCallerReachoutTimelocked: 463 in WhatsApp Web, plus a query that returns whether the lock is active, its type and its end time (Baileys 2441, 25 March 2026).
• What the lock gates. The client code lets a restricted account message itself, business accounts, support accounts, bots, and any chat for which it holds a trusted-contact token (tctoken). WhatsApp hands out that privacy token as two accounts exchange messages. A new chat has none, which matches WhatsApp’s help page.
• The types. Baileys ships an enum of enforcement types read from the web client. It includes WEB_COMPANION_ONLY, BIZ_QUALITY and 15 BIZ_COMMERCE_VIOLATION_* values, and WAHA also lists RESTRICT_ALL_COMPANIONS. That suggests a general enforcement tool, not only a volume limit (an inference).
• A library bug made it worse. The maintainers’ hypothesis was that sends without privacy tokens counted toward the limit. Fixes followed: Baileys pull requests 2257 (merged 17 January 2026) and 2339 (24 April), then release 7.0.0-rc10 on 6 May 2026, which sends tctokens and adds fetchAccountReachoutTimelock() and a reachoutTimeLock field on connection.update. whatsmeow merged its tctoken lifecycle on 27 April 2026.
• Tokens are not the whole story. Users on 7.0.0-rc14 (29 July 2026) still reported 463 in August, and the maintainers concluded it is an account restriction, not just a missing token.

WAHA turned this into documented endpoints. Since release 2026.8.1 (14 August 2026), GET /api/sessions/{session}/timelock returns isActive, timeEnforcementEnds and enforcementType, and a session.status event reports changes. WAHA also documents a second, volume-based limit: message capping, which fails sends with error 475 until a quota cycle resets.

Evolution API is a separate case. Its latest stable release (2.3.7, December 2025) and its main branch pin baileys 7.0.0-rc.9 (21 November 2025), which predates tctoken sending, while the develop branch uses rc13. One user reported fixing a fresh session by bumping Baileys to rc13 themselves.

Which claims are still unconfirmed?

What should you do when you see 463?

1. Stop messaging new contacts from that number. Keep answering chats that already exist.
2. Read the state instead of guessing. Use fetchAccountReachoutTimelock() in Baileys, WAHA’s timelock endpoint, or New Chat on the phone.
3. Do not restart, log out or re-pair. WAHA’s documentation says this does not lift the restriction, and one contributor’s tests found that retries, new tokens and a cstoken fallback do not either.
4. Check your dependency. Use Baileys 7.0.0-rc10 or later, and confirm what your wrapper pins.
5. Log acks, not only HTTP status. Some wrappers return success while WhatsApp rejects the message.
6. Wait for the end time. The restriction lifts on its own.

Why do designs where users write first avoid it?

The restriction targets the first move: starting chats with people who never wrote. WhatsApp’s own advice is to message people who contacted you first. A system where the user opens the chat, for example from a wa.me link, never makes that move, so the lock has nothing to act on.

whasp enforces this in the API. A number cannot open a chat cold (409 chat_not_open), and its health turns at_risk when WhatsApp warns or restricts it. Its numbers run the WhatsApp app on a phone rather than a protocol library, so token handling is the app’s job, not yours. This does not make bans impossible: users can still block or report a number, and WhatsApp decides. A banned number is replaced at no cost, but chats do not move. See why WhatsApp bans numbers.

Where to go next

If you run Baileys, WAHA or Evolution API, update the dependency, log acks and add a rule that blocks new-contact sends while a timelock is active. To compare the options, read the unofficial API comparison. If a number is already banned, start with what to do next. For new numbers, see warming up a WhatsApp number.