Describe the bug
Outbound messages sent via POST /api/sendText fail with HTTP 500 / error 463 when using the GOWS engine for specific contacts, even though the session is WORKING, inbound messages arrive normally, and messages sent directly from the physical device succeed.
We run 30 active WAHA instances (GOWS engine, different phone numbers). This is the first session we have ever seen this issue on. The failure affected 14 different contacts in that single session — all returning the same error 463 — while other instances continued operating normally. The issue occurs regardless of chatId format (@c.us or @lid).
Version
{
"version": "2026.3.2",
"engine": "GOWS",
"tier": "PLUS"
}
Steps
To Reproduce:
- Start a WAHA session using the GOWS engine — session reaches
WORKING state
- Confirm inbound messages are being received normally
- Send a message from the physical device — succeeds
- Call
POST /api/sendText with a valid session and chatId
- Receive HTTP 500 with
"2 UNKNOWN: server returned error 463"
Expected behavior
POST /api/sendText should succeed for any contact reachable from the device, matching the behavior of the physical device and the WEBJS engine.
Requests - Responses
Request:
POST /api/sendText
{
"session": "<session-id>",
"chatId": "557398669599@c.us",
"text": "Hello"
}Response (HTTP 500):
{
"error": "2 UNKNOWN: server returned error 463"
}Tested with both @c.us and @lid chatId formats — both return the same error 463.
Docker Logs
Failed to send text message | status=500 | errorMessage="Request failed with status code 500" | session=<session-id> | chatId=557398669599@c.us
Screenshots
Session status in WAHA dashboard:
- Status:
WORKING
- Account: authenticated and active
- Server: WAHA
Additional context
After investigating, we believe this is caused by the absence of the tctoken lifecycle in the GOWS engine.
WhatsApp now requires a valid privacy token (tctoken) in every outbound DM. When the token is missing or expired, the server rejects the message with error 463 (NackCallerReachoutTimelocked). This is not a session issue — the session is WORKING, receives messages, and the physical device sends without problems.
This was addressed in whatsmeow via:
- tulir/whatsmeow#1081 — full
tctoken lifecycle: proactive fetch before send, 28-day expiration window, async token issuance after send
- tulir/whatsmeow#1104 — diagnostic APIs for account-level capping and reachout timelock
WEBJS does not reproduce this issue, suggesting the fix is already present there. GOWS appears to be missing the equivalent implementation.
Could the GOWS engine receive parity with the tctoken handling from whatsmeow PR #1081?
Describe the bug
Outbound messages sent via
POST /api/sendTextfail with HTTP 500 / error 463 when using the GOWS engine for specific contacts, even though the session isWORKING, inbound messages arrive normally, and messages sent directly from the physical device succeed.We run 30 active WAHA instances (GOWS engine, different phone numbers). This is the first session we have ever seen this issue on. The failure affected 14 different contacts in that single session — all returning the same error 463 — while other instances continued operating normally. The issue occurs regardless of chatId format (
@c.usor@lid).Version
{ "version": "2026.3.2", "engine": "GOWS", "tier": "PLUS" }Steps
To Reproduce:
WORKINGstatePOST /api/sendTextwith a validsessionandchatId"2 UNKNOWN: server returned error 463"Expected behavior
POST /api/sendTextshould succeed for any contact reachable from the device, matching the behavior of the physical device and the WEBJS engine.Requests - Responses
Request:
Response (HTTP 500):
{ "error": "2 UNKNOWN: server returned error 463" }Tested with both
@c.usand@lidchatId formats — both return the same error 463.Docker Logs
Screenshots
Session status in WAHA dashboard:
WORKINGAdditional context
After investigating, we believe this is caused by the absence of the
tctokenlifecycle in the GOWS engine.WhatsApp now requires a valid privacy token (
tctoken) in every outbound DM. When the token is missing or expired, the server rejects the message with error 463 (NackCallerReachoutTimelocked). This is not a session issue — the session isWORKING, receives messages, and the physical device sends without problems.This was addressed in whatsmeow via:
tctokenlifecycle: proactive fetch before send, 28-day expiration window, async token issuance after sendWEBJS does not reproduce this issue, suggesting the fix is already present there. GOWS appears to be missing the equivalent implementation.
Could the GOWS engine receive parity with the
tctokenhandling from whatsmeow PR #1081?