Inoffizielle WhatsApp-API im Vergleich: Baileys, WAHA & Co.

Baileys und whatsmeow sind Bibliotheken, whatsapp-web.js steuert einen Browser, WAHA und Evolution API verpacken sie in einen REST-Server, und Whapi.Cloud und Green-API hosten dieselbe Idee. Sie unterscheiden sich in Sprache, Lizenz und Reifegrad, aber alle melden sich an einem WhatsApp-Account an, der dir gehört, und steuern ihn per Code. Die Nummer, das Telefon und die Sperre sind deine.

Welche solltest du nehmen?

• Go oder ein minimaler Footprint: whatsmeow für Go, Baileys für TypeScript. Beide sprechen über einen WebSocket mit WhatsApp und brauchen keinen Browser.
• Diese Woche eine funktionierende REST-API: WAHA. Es läuft in Docker mit Swagger, Dashboard und Webhooks und bringt alle zwei bis drei Wochen ein Release heraus.
• Chatwoot, Typebot oder Dify im Stack: Evolution API, das diese Integrationen mitbringt und auch Metas offizielle Cloud API nutzen kann.
• Der echte Web-Client, mit Chromium als Preis: whatsapp-web.js.
• Keine Server betreiben: Whapi.Cloud oder Green-API, die trotzdem deine eigene Nummer verknüpfen.
• Eine Nummer, bei der das Risiko nicht bei dir liegt: eine verwaltete Nummer wie whasp oder die offizielle Plattform für geschäftsspezifische Bots.

Wie schneiden sie im Vergleich ab?

Alle dokumentieren Gruppen, Medien, Reaktionen und Umfragen. whatsapp-web.js nennt zusätzlich Kanäle und braucht für den Videoversand Google Chrome statt Chromium.

Was unterscheidet die einzelnen Optionen?

Baileys hat 11,4k GitHub-Sterne. Seine README beschreibt eine WebSocket-basierte Bibliothek, die kein Selenium und keinen Browser braucht. Version 7 hat lange gedauert: rc9 erschien am 21. November 2025, rc10 am 6. Mai 2026, und rc14 vom 29. Juli 2026 ist die neueste. Die Hinweise zu rc11 der Maintainer sagen, dass die Abhängigkeit libsignal unter GPLv3 steht, während Baileys unter MIT steht, und dass sie sie ersetzen wollen. Lies das, bevor du es kommerziell einsetzt.

whatsapp-web.js lässt WhatsApp Web über Puppeteer in einem verwalteten Chromium laufen. Das bedeutet mehr Speicher, aber es nutzt den echten Web-Client. Es braucht Node 18 oder neuer, und das letzte Release ist 1.34.7 (24. April 2026), mit Commits bis Ende September.

whatsmeow ist die Go-Bibliothek unter der GOWS-Engine von WAHA. Es ist die einzige Bibliothek in dieser Liste mit gemergtem Passkey-Support.

WAHA ist ein Server und keine Bibliothek. WEBJS, der Standard, und WPP lassen einen Browser laufen. NOWEB (Node.js, auf Basis von Baileys) und GOWS (Go) nutzen einen WebSocket. Seit Release 2026.6.1 stecken Funktionen, die früher nur in Plus enthalten waren, im kostenlosen Core-Image. WAHA dokumentiert auch den Reachout Timelock und liefert eine MCP-App mit.

Evolution API ergänzt Hooks für Typebot, Chatwoot, Dify, OpenAI, RabbitMQ und Kafka sowie einen Cloud-API-Modus. Die Lizenz ist Apache-2.0 mit Zusatzbedingungen zur Anzeige der Marke und zur Benachrichtigung von Nutzern, lies also die Datei. Das letzte stabile Release ist 2.3.7 (5. Dezember 2025), und der Main-Branch pinnt Baileys 7.0.0-rc.9, während der Develop-Branch rc13 nutzt.

Whapi.Cloud und Green-API verkaufen dasselbe Modell mit verknüpftem Account als Dienst. Die kostenlose Sandbox von Whapi erlaubt 5 aktive Unterhaltungen im Monat, und der Gratis-Tarif von Green-API erlaubt 3 Chats.

Welche warnen dich, bevor eine Einschränkung zuschlägt?

Nicht alle machen den Einschränkungsstatus von WhatsApp sichtbar. Baileys hat seit rc10 fetchAccountReachoutTimelock() und ein Update reachoutTimeLock. WAHA bietet seit Release 2026.8.1 einen Timelock-Endpoint für GOWS, NOWEB und WEBJS. whatsmeow hat sein Handling der Trusted-Contact-Tokens am 27. April 2026 gemergt, während ein Pull Request, der den Timelock und die Message Caps prüft, seit dem 25. März offen ist. In whatsapp-web.js haben wir nichts Vergleichbares gefunden, und Evolution API bekommt diese Funktionen nur über die Baileys-Version, die es pinnt. Einzelheiten stehen in der Erklärung zum Fehler 463.

Was hat die Passkey-Änderung vom Juni 2026 kaputt gemacht?

Am 30. Juni 2026 erhielten die Tracker von Baileys, WAHA, Evolution API, whatsapp-web.js und whatsmeow denselben Bericht. Nachdem der QR-Code oder der Pairing-Code akzeptiert war, verlangte WhatsApp einen Passkey, und die Verknüpfung wurde nie fertig. Es traf einige Accounts, nicht alle. WAHA schreibt von „some accounts“, und Green-API sagt, WhatsApp habe im Sommer 2026 einen experimentellen Umstieg für einige Nutzer begonnen. Eine Ankündigung von WhatsApp haben wir nicht gefunden.

Eine Community-Analyse in Baileys-Issue 2672, erstellt aus einem whatsmeow-Mitschnitt und dem Code von WhatsApp Web, sagt, der Server schicke nach dem Pairing eine WebAuthn-Anfrage mit dem internen Codenamen „Shortcake“, bei der eine Nutzerverifizierung verlangt wird. Ihr Autor kennzeichnet, was beobachtet und was gefolgert wurde. Die Folge ist, dass ein Headless-Client sie nicht allein signieren kann, also muss eine Person mit einem Authenticator mitwirken.

So steht es um die einzelnen Projekte:

• whatsmeow: hat den Passkey-Support gemergt, am 1. Juli 2026.
• WAHA: Die GOWS-Engine bekam ihn in Release 2026.7.1 (15. Juli). Eine Browser-Erweiterung signiert die Challenge. NOWEB, WEBJS und WPP waren im Tracking-Issue von WAHA noch nicht abgehakt.
• Baileys: Nichts ist gemergt. Ein Pull Request mit dem Handshake wurde am 20. August ungemergt geschlossen, ein zweiter am 4. September, und das Issue ist offen. Der letzte Commit auf master stammt vom 4. August.
• Evolution API: Ein Pull Request ist seit dem 7. Juli offen.
• whatsapp-web.js: Das Issue wurde am 19. August vom Stale-Bot ohne Fix geschlossen.

Seit Mitte Juli sagen manche Nutzer, ihre Accounts würden nicht mehr danach gefragt. Das ist anekdotisch, und nur WhatsApp weiß, ob es zurückgenommen wurde. Workarounds kopieren eine Session aus einem echten WhatsApp-Web-Tab in die Bibliothek. Dabei wandert Schlüsselmaterial aus einem Browserprofil heraus, behandle es also als sensibel.

Welches Problem haben alle gemeinsam?

Jede Option außer der offiziellen Plattform verknüpft einen Account, der dir gehört, als inoffiziellen Client. Die Hilfeseite zu verknüpften Geräten von WhatsApp sagt, dass das Verknüpfen eines Accounts mit einer inoffiziellen App oder Website, jetzt oder früher, zu einer vorübergehenden oder dauerhaften Sperre führen kann. Sie sagt auch, dass verknüpfte Geräte abgemeldet werden, wenn das Telefon länger als 14 Tage nicht benutzt wird. WAHA und Baileys tragen ähnliche Warnungen in ihren eigenen Disclaimern. Siehe warum WhatsApp Nummern sperrt und den Fehler 463.

Du trägst also die Sperre, und du betreibst die Session, das Telefon und das Aufwärmen (Warm-up). Gehostete Dienste nehmen dir die Server ab, nicht das Risiko.

Wo unterscheidet sich whasp?

whasp betreibt die Nummer: ein echter persönlicher WhatsApp-Account auf einem eigenen Cloud-Telefon und einer eigenen ISP-IP, aufgewärmt, mit Health-Monitoring. Du bekommst einen Webhook und einen API-Aufruf. Wird eine Nummer gesperrt, wird sie kostenlos mit demselben Profil ersetzt, aber die Chats ziehen nicht um. Sie kostet $49 pro Nummer alle 30 Tage, für etwa 100 aktive Nutzer.

Die Kompromisse sind real. Nutzer müssen zuerst schreiben, es gibt keine Gruppen, keine ausgehenden Sprachnachrichten und keine mitgebrachte eigene Nummer. Eine Bibliothek bietet Gruppen und mehr Funktionen, mit dem Risiko auf deinem eigenen Account. Für geschäftsspezifische Bots wie Support oder Bestellungen ist die offizielle Plattform oft die richtige Antwort. Metas Bedingungen schließen allgemeine KI-Assistenten von ihr aus, wie in WhatsApp KI-Chatbot-Verbot 2026: Regel und aktueller Stand beschrieben.

Wie geht es weiter?

Für alle Wege, offiziell und inoffiziell, lies KI-Agent auf WhatsApp: alle Optionen im Vergleich. Um Claude oder ChatGPT anzubinden, siehe WhatsApp MCP Server. Einzelheiten und Preise stehen auf der Preisseite.