WhatsApp-Fehler 463: Was der Reachout Timelock bedeutet

Der WhatsApp-Fehler 463 kommt bei einer Bibliothek wie Baileys oder WAHA an, wenn WhatsApp eine Nachricht nicht sendet, weil der Account unter einem Reachout Timelock steht: einer vorübergehenden Einschränkung, Chats mit Leuten zu beginnen, mit denen er noch nie geschrieben hat. Bestehende Chats laufen weiter, und die Einschränkung endet von selbst. WhatsApp beschreibt die Einschränkung, nennt den Code aber nirgends.

Wie sieht der Fehler 463 in deinen Logs aus?

Der Fehler 463 taucht je nach Bibliothek unter verschiedenen Namen auf. whatsmeow und die GOWS-Engine von WAHA liefern server returned error 463. Baileys erhält ein Nachrichten-Ack mit error='463' und schreibt messageStubParameters: ["463"]. Evolution API, das Baileys einbindet, zeigt oft nichts außer einer Nachricht, die in PENDING hängt, obwohl der HTTP-Aufruf gelungen ist. Der Code erscheint dort also nur mit LOG_BAILEYS=trace, wie ein Nutzer im Untersuchungsthread von Baileys berichtete.

Die ersten öffentlichen Berichte, die wir gefunden haben, stammen vom 12. Februar 2026 (whatsmeow-Issue 1074). Die Baileys-Maintainer eröffneten ihre Untersuchung am 25. März 2026, und der GOWS-Bericht von WAHA folgte am 31. März 2026. Er war am 19. Oktober 2026 noch offen.

Was bestätigt WhatsApp selbst?

Die Hilfeseite von WhatsApp Über eingeschränkte Accounts bestätigt das Verhalten, ohne den Fehler zu nennen. In der App kann ein Account die Meldung „Your account is restricted right now“ sehen oder eine Warnung, dass er bald eingeschränkt werden könnte. Die Seite sagt:

• Die Einschränkung endet nach einer festgelegten Zeit automatisch, und WhatsApp schickt eine Benachrichtigung, wenn es so weit ist.
• Um die verbleibende Zeit zu sehen, tippe auf „Neuer Chat“ und wähle einen Kontakt, mit dem du noch nie geschrieben hast.
• Ursache ist jüngste Aktivität, die Anzeichen von Spam oder von automatisierten oder Massennachrichten zeigen könnte.
• Du kannst weiter mit Kontakten und Gruppen kommunizieren, mit denen du Chats oder Anrufe ausgetauscht hast.
• Du kannst keine Chats oder Anrufe mit neuen Kontakten beginnen, keine Gruppen erstellen, keine Mitglieder zu Gruppen hinzufügen und keine verknüpften Geräte nutzen, und es kann sein, dass du auf manchen Companion-Geräten abgemeldet wirst.

Eine zweite Seite, WhatsApp verantwortungsvoll nutzen, rät, nur Leuten zu schreiben, die dich zuerst kontaktiert haben oder darum gebeten haben, kontaktiert zu werden. Sie fügt hinzu, dass WhatsApp maschinelles Lernen und Nutzermeldungen einsetzt, um unerwünschte automatisierte Nachrichten zu erkennen.

WhatsApp veröffentlicht weder den Code 463 noch das Wort „Timelock“, weder Schwellenwerte noch Dauern. Auch Metas Referenz der Cloud-API-Fehler führt 463 nicht auf.

Was haben Entwickler herausgefunden?

Entwickler haben 463 der Einschränkung zugeordnet, indem sie den eigenen Code von WhatsApp Web gelesen haben. Das ist gut belegtes Reverse Engineering, keine Dokumentation. Die wichtigsten Funde:

• Der Name. Ein Baileys-Maintainer fand in WhatsApp Web NackCallerReachoutTimelocked: 463 und eine Abfrage, die zurückgibt, ob der Timelock aktiv ist, welchen Typ er hat und wann er endet (Baileys 2441, 25. März 2026).
• Was der Timelock sperrt. Der Client-Code erlaubt einem eingeschränkten Account, sich selbst, Business-Accounts, Support-Accounts, Bots und jedem Chat zu schreiben, für den er ein Trusted-Contact-Token (tctoken) besitzt. WhatsApp verteilt dieses Privacy-Token, während zwei Accounts Nachrichten austauschen. Ein neuer Chat hat keins, was zur Hilfeseite von WhatsApp passt.
• Die Typen. Baileys liefert ein Enum mit Durchsetzungstypen aus, das aus dem Web-Client gelesen wurde. Es enthält WEB_COMPANION_ONLY, BIZ_QUALITY und 15 Werte BIZ_COMMERCE_VIOLATION_*, und WAHA listet außerdem RESTRICT_ALL_COMPANIONS. Das deutet auf ein allgemeines Durchsetzungswerkzeug hin, nicht nur auf ein Mengenlimit (eine Schlussfolgerung).
• Ein Fehler in der Bibliothek verschlimmerte es. Die Hypothese der Maintainer war, dass Sendungen ohne Privacy-Tokens auf das Limit angerechnet wurden. Es folgten Fixes: Baileys-Pull-Requests 2257 (gemergt am 17. Januar 2026) und 2339 (24. April), dann Release 7.0.0-rc10 am 6. Mai 2026, das tctokens sendet und fetchAccountReachoutTimelock() sowie ein Feld reachoutTimeLock in connection.update hinzufügt. whatsmeow hat seinen tctoken-Lebenszyklus am 27. April 2026 gemergt.
• Tokens sind nicht die ganze Geschichte. Nutzer von 7.0.0-rc14 (29. Juli 2026) meldeten im August weiterhin 463, und die Maintainer folgerten, dass es eine Einschränkung des Accounts ist und nicht nur ein fehlendes Token.

WAHA hat daraus dokumentierte Endpoints gemacht. Seit Release 2026.8.1 (14. August 2026) liefert GET /api/sessions/{session}/timelock die Felder isActive, timeEnforcementEnds und enforcementType, und ein session.status-Event meldet Änderungen. WAHA dokumentiert außerdem ein zweites, mengenbasiertes Limit: das Message Capping, bei dem Sendungen mit dem Fehler 475 scheitern, bis ein Kontingentzyklus zurückgesetzt wird.

Evolution API ist ein Sonderfall. Das letzte stabile Release (2.3.7, Dezember 2025) und der Main-Branch pinnen baileys 7.0.0-rc.9 (21. November 2025), das älter ist als das Senden von tctokens, während der Develop-Branch rc13 nutzt. Ein Nutzer berichtete, er habe eine frische Session repariert, indem er Baileys selbst auf rc13 angehoben habe.

Welche Behauptungen sind noch unbestätigt?

Was tun bei Fehler 463?

1. Schreib von dieser Nummer keine neuen Kontakte mehr an. Beantworte weiter Chats, die schon bestehen.
2. Lies den Zustand, statt zu raten. Nutze fetchAccountReachoutTimelock() in Baileys, den Timelock-Endpoint von WAHA oder „Neuer Chat“ auf dem Telefon.
3. Starte nicht neu, melde dich nicht ab und koppel nicht neu. Laut der Dokumentation von WAHA hebt das die Einschränkung nicht auf, und die Tests eines Contributors ergaben, dass auch Wiederholungen, neue Tokens und ein cstoken-Fallback nichts bringen.
4. Prüfe deine Abhängigkeit. Nutze Baileys 7.0.0-rc10 oder neuer und prüfe, welche Version dein Wrapper pinnt.
5. Logge die Acks, nicht nur den HTTP-Status. Manche Wrapper melden Erfolg, während WhatsApp die Nachricht ablehnt.
6. Warte auf die Endzeit. Die Einschränkung endet von selbst.

Warum vermeiden Designs, bei denen Nutzer zuerst schreiben, das Problem?

Die Einschränkung zielt auf den ersten Schritt: Chats mit Leuten zu beginnen, die nie geschrieben haben. WhatsApps eigener Rat lautet, Leuten zu schreiben, die dich zuerst kontaktiert haben. Ein System, in dem der Nutzer den Chat öffnet, zum Beispiel über einen wa.me-Link, macht diesen Schritt nie, der Timelock hat also nichts, woran er ansetzen kann.

whasp setzt das in der API durch. Eine Nummer kann keinen Chat kalt eröffnen (409 chat_not_open), und ihr Health-Status springt auf at_risk, wenn WhatsApp warnt oder einschränkt. Die Nummern von whasp betreiben die WhatsApp-App auf einem Telefon statt einer Protokoll-Bibliothek, das Token-Handling ist also Sache der App und nicht deine. Das macht Sperren nicht unmöglich: Nutzer können eine Nummer weiterhin blockieren oder melden, und WhatsApp entscheidet. Eine gesperrte Nummer wird kostenlos ersetzt, aber die Chats ziehen nicht um. Siehe warum WhatsApp Nummern sperrt.

Wie geht es weiter?

Wenn du Baileys, WAHA oder Evolution API betreibst, aktualisiere die Abhängigkeit, logge die Acks und füge eine Regel hinzu, die Sendungen an neue Kontakte blockiert, solange ein Timelock aktiv ist. Für einen Vergleich der Optionen lies den Vergleich inoffizieller APIs. Ist eine Nummer schon gesperrt, beginne mit was du als Nächstes tun kannst. Für neue Nummern siehe eine WhatsApp-Nummer aufwärmen.