Irgendwann kommt in fast jedem Access-Projekt die Frage: Kann die Datenbank nicht einfach eine WhatsApp schicken, wenn ein Auftrag fertig ist, ein Lagerbestand kippt oder ein Termin ansteht? E-Mail ist eingebaut, SMS kostet pro Stück, und WhatsApp liest fast jeder innerhalb von Minuten. Die ehrliche Antwort lautet: Ja, technisch geht das, und einfacher als die meisten denken. Die unehrliche Antwort wäre, die Haken zu verschweigen.
Dieser Beitrag schaut sich OpenWA an, ein selbstgehostetes WhatsApp-Gateway, und beantwortet drei Fragen. Wie steuert man WhatsApp aus Access an, senden wie empfangen? Was kosten die Mitbewerber? Und wo zieht das deutsche Recht die Grenze?
Was OpenWA ist
OpenWA ist ein quelloffenes, selbstgehostetes Gateway, das eine WhatsApp-Nummer über eine lokale HTTP-Schnittstelle ansprechbar macht. Statt WhatsApp manuell zu tippen, schickst du einen JSON-Aufruf an http://localhost:2785/api, abgesichert über einen API-Schlüssel im Header, und das Gateway versendet die Nachricht.
Unter der Haube steuert OpenWA eine echte WhatsApp-Web-Sitzung. Die Anmeldung läuft einmalig per QR-Code, danach hängt deine Nummer als „verknüpftes Gerät“ am Gateway, technisch wie ein zweiter Browser-Tab. Das Projekt steht unter MIT-Lizenz, ist in Node.js geschrieben und noch sehr jung. Mit Version 0.1.x würde ich es als interessant einstufen, nicht als abgehangen.
Ein Hinweis gegen Verwechslung: Es gab früher ein Node-Paket namens open-wa beziehungsweise wa-automate. Das hier ist ein neueres, anderes Projekt unter open-wa.org. Wer im Netz sucht, landet leicht beim falschen.
Für die Installation gibt es zwei Wege: per Docker oder per npm. Wer ohnehin Node.js und npm auf der Maschine hat, etwa weil dort eine KI-CLI oder andere Kommandozeilen-Werkzeuge laufen, kann Docker komplett überspringen. Ein git clone, ein npm install, ein npm run dev, und das Gateway läuft. Das ist für Access-Leute, die mit Containern fremdeln, der angenehmere Pfad.
Was dafür spricht
Drei Punkte machen OpenWA für die Access-Welt attraktiv:
- Kostenlos und selbstgehostet. Keine Lizenzgebühr, kein Konto bei einem Dienstleister, die Daten bleiben auf deinem Server.
- Sprachunabhängige REST-Schnittstelle. Alles, was HTTP sprechen kann, kann das Gateway ansprechen: VBA, PHP, T-SQL über CLR, egal. Du musst dich nicht in ein SDK einarbeiten.
- Eine normale Nummer reicht. Kein Business-Verifizierungs-Verfahren, keine Vorlagen-Genehmigung. Senden, Empfangen, Gruppen und Medien funktionieren mit einer gewöhnlichen WhatsApp-Nummer.
Wo es hakt
Genau diese Leichtigkeit ist zugleich das Problem. Vier Einschränkungen muss man kennen, bevor man das in irgendetwas Ernstes einbaut:
- Inoffizieller Client. OpenWA spricht nicht die offizielle WhatsApp-Schnittstelle, sondern automatisiert WhatsApp Web. Das verstößt gegen die Nutzungsbedingungen von WhatsApp, und gerade bei höherem Volumen riskierst du die Sperrung der Nummer.
- Fragil. Sobald Meta das Protokoll von WhatsApp Web ändert, kann das Gateway brechen, bis die Entwickler nachziehen. Das ist kein Versagen von OpenWA, sondern bei jedem inoffiziellen Ansatz so.
- Junges Projekt. Version 0.1.x heißt: vieles funktioniert, aber Produktionsreife im Sinne von „läuft seit Jahren stabil bei vielen“ gibt es noch nicht.
- Access ist nur der Client. Das Gateway muss als dauerhaft laufender Node-Prozess im Hintergrund liegen. Geht die Maschine abends aus, sendet nichts. Und die Sitzung kann abreißen, ohne dass jemand es merkt. Eine Zustellgarantie gibt es nicht.
Senden aus Access: der einfache Teil
Aus Access ist das Senden ein simpler HTTP-Aufruf. Wer schon einmal eine REST-Schnittstelle per WinHttpRequest angesprochen hat, kennt das Muster, der Rest ist nur die richtige URL und ein JSON-Rumpf. Das folgende Beispiel ist das Standard-Muster, kein getesteter Produktiv-Code, und soll nur die Größenordnung des Aufwands zeigen:
Public Sub WhatsAppSenden(chatId As String, text As String)
Dim http As Object
Set http = CreateObject("WinHttp.WinHttpRequest.5.1")
http.Open "POST", "http://localhost:2785/api/sessions/my-bot/messages/send-text", False
http.SetRequestHeader "Content-Type", "application/json"
http.SetRequestHeader "X-API-Key", "DEIN_KEY"
http.Send "{""chatId"":""" & chatId & """,""text"":""" & text & """}"
Debug.Print http.Status, http.ResponseText
End Sub
Mehr ist es nicht. Die chatId ist bei einer Einzelperson die Nummer ohne Plus und ohne führende Null, gefolgt von @c.us, bei einer Gruppe endet sie auf @g.us. Den JSON-Rumpf würde man in der Praxis sauberer zusammenbauen als per String-Verkettung, aber das Prinzip bleibt: ein Aufruf, eine Antwort, fertig. Für einen Access-Entwickler mit HTTP-Erfahrung ist das eine Stunde Arbeit, nicht ein Projekt.
Empfangen in Access: der unbequeme Teil
Das Senden ist trivial. Das Empfangen ist der Teil, an dem die meisten den Aufwand unterschätzen. OpenWA liefert eingehende Nachrichten nicht auf Abruf, sondern per Webhook: Es schickt jede neue Nachricht aktiv an eine HTTP-Adresse, die du hinterlegst. Access ist aber kein Webserver, es kann nichts entgegennehmen, das von außen hereingedrückt wird.
Daraus folgt eine klare Architektur. Du brauchst ein kleines Zwischenstück, das die Webhooks annimmt und in eine Tabelle schreibt, am sinnvollsten ein paar Zeilen PHP oder ein schlankes Endpoint auf dem Server, der die eingehende Nachricht in eine SQL-Server-Tabelle einträgt. Access liest diese Tabelle dann ganz normal als verknüpfte Tabelle, entweder per Timer-Formular im Sekundentakt oder beim Öffnen der passenden Maske.
Aus meiner Praxis im norddeutschen Mittelstand zeigt sich: Diese Tabelle-als-Briefkasten-Lösung ist nicht hübsch, aber robust. Sie entkoppelt das fragile Gateway vom Frontend. Fällt OpenWA aus, läuft Access weiter, es kommt nur nichts Neues rein. Und die eingehenden Nachrichten liegen dauerhaft in der Datenbank, auswertbar, durchsuchbar, mit Zeitstempel. Wer es ganz ohne Zwischenstück will, kann OpenWA auch periodisch per REST nach neuen Nachrichten fragen, das ist aber unsauberer und belastet das Gateway unnötig.
Die Mitbewerber und was sie kosten
OpenWA ist nicht allein. Der Markt teilt sich in zwei Welten, und der Preisunterschied erklärt sich fast vollständig aus „offiziell oder nicht“.
Auf der inoffiziellen Seite, also derselben Risikoklasse wie OpenWA, stehen vor allem zwei Namen. whatsapp-web.js und Baileys sind die freien Bibliotheken, die unter der Haube die eigentliche Arbeit machen, auch bei OpenWA selbst. Wer alles selbst bauen will, nimmt direkt eine davon, kostenlos, aber ohne fertige REST-Schnittstelle. WAHA (WhatsApp HTTP API) ist der etabliertere Bruder von OpenWA: die Core-Version ist kostenlos und quelloffen, die erweiterte Plus-Version läuft über ein Spendenmodell statt klassischem Abo und hat keine Lizenz, die abläuft. Auch WAHA steuert im Hintergrund eine echte WhatsApp-Web-Instanz, um Sperren zu vermeiden.
Ein Sonderfall ist Green API, ein Cloud-Gateway. Der „Developer“-Tarif ist kostenlos mit Einschränkungen, der „Business“-Tarif kostet rund 690 Rubel pro Monat. Für eine deutsche Datensouveränitäts-Sicht hat Green API allerdings einen Haken, auf den ich im Rechts-Abschnitt zurückkomme.
Auf der offiziellen Seite steht die WhatsApp Business Cloud API von Meta. Hier kommt ein neuer Begriff ins Spiel. Ein BSP (Business Solution Provider) ist ein von Meta zugelassener Vermittler wie 360dialog oder Twilio, über den die offizielle Schnittstelle überhaupt erst zugänglich wird. Die Kosten haben zwei Schichten: eine Plattformgebühr beim BSP und eine Gebühr pro Nachricht an Meta. Die offizielle API kostet je nach Anbieter zwischen 0 und 99 US-Dollar pro Monat plus die Gebühren pro Konversation, dafür gibt es kein Sperr-Risiko. Eine Marketing-Konversation in Deutschland liegt bei etwa 0,075 Euro, deutlich teurer als in Märkten wie Indien. Vom Kunden ausgelöste Service-Antworten innerhalb des 24-Stunden-Fensters sind seit November 2024 kostenlos.
Die Faustregel daraus: Für reaktive, eingehende Kommunikation auf kleinem Volumen taugt ein inoffizielles Gateway. Für produktiven Einsatz in jeder Größenordnung ist die offizielle API der Weg, das inoffizielle WAHA empfiehlt sich nur für eingehend-reaktive Bots auf niedrigem Volumen.
Rechtliche Grenzen in Deutschland
Hier wird es für KMU ernst, und der Punkt ist wichtiger als jedes Code-Detail. Drei Ebenen gehören auseinandergehalten.
Nutzungsbedingungen. Jeder inoffizielle Client, OpenWA, WAHA, Baileys, verstößt gegen die WhatsApp-Bedingungen. Das ist kein deutsches Recht, sondern Vertragsrecht gegenüber Meta, mit der praktischen Folge, dass die Nummer jederzeit gesperrt werden kann. Ein Kanal, der dir von heute auf morgen wegbrechen darf, ist kein Kanal, den man einem Kunden als verlässliche Infrastruktur verkauft.
Datenschutz. Hier entscheidet der Zweck. Privat und im Freundeskreis greift die Haushaltsausnahme nach Artikel 2 Absatz 2 Buchstabe c DSGVO, dann brauchst du weder Auftragsverarbeitungsvertrag noch Rechtsgrundlage. Sobald es geschäftlich wird, also Kundenkommunikation, kippt das. Du brauchst eine Rechtsgrundlage und einen Auftragsverarbeitungsvertrag mit Meta, und diesen Vertrag bekommst du nur über die offizielle Business-Schnittstelle, nicht über die Hintertür eines inoffiziellen Gateways. Die Inhalte laufen in beiden Fällen über Metas Server in den USA, nur ist der Drittlandtransfer beim offiziellen Weg vertraglich abgesichert und beim inoffiziellen eben nicht.
Wettbewerbsrecht. Unaufgeforderte Werbung per WhatsApp ist nach Paragraf 7 UWG nur mit vorheriger ausdrücklicher Einwilligung erlaubt. Wer Bestandskunden ungefragt anschreibt, riskiert eine Abmahnung, unabhängig davon, mit welchem technischen Werkzeug die Nachricht rausging.
Und der versprochene Haken bei Green API: Der Anbieter ist in Russland ansässig. Für ein deutsches Unternehmen kommt damit ein zusätzlicher Drittlandtransfer in ein Land ohne Angemessenheitsbeschluss ins Spiel, der die datenschutzrechtliche Lage gegenüber einem selbstgehosteten Gateway eher verschlechtert als verbessert.
Der stehende Satz für die ganze Frage: Bei WhatsApp aus Access ist nicht der API-Aufruf das Risiko, sondern ob darunter ein vertraglich und betrieblich tragfähiger Kanal liegt.
Ehrliche Einschränkung
OpenWA ist ein gutes Werkzeug für den richtigen Zweck, und ein schlechtes für den falschen. Für interne Benachrichtigungen, für einen Alarm an dich selbst, für einen privaten Kreis bekannter Empfänger auf Einwilligungsbasis ist es in ein, zwei Stunden angebunden und tut, was es soll. Als skalierbarer Kundenkanal für ein KMU würde ich es nicht einsetzen, da gehört die offizielle Cloud API über einen BSP hin, gleiche Access-Seite, völlig andere Risikoklasse darunter.
Disclaimer
Dieser Beitrag ist eine technische Einordnung, keine Rechtsberatung. Ich bin kein Anwalt. WhatsApp-Automatisierung über inoffizielle Gateways verstößt gegen die Nutzungsbedingungen von WhatsApp und kann zur Sperrung der genutzten Nummer führen. Wer das geschäftlich einsetzen will, sollte vorher eine datenschutzrechtliche Einschätzung einholen. Das gezeigte VBA ist ein illustratives Muster, kein getesteter Produktiv-Code.
Wenn dich die andere Seite interessiert
Wenn dich an dem Thema nicht der Code reizt, sondern die Frage, ob sich so ein Kanal für dein Unternehmen überhaupt rechnet und rechtlich trägt: Genau diese Abwägung zwischen schneller Bastellösung und tragfähiger Anbindung an Bestandssysteme ist mein Tagesgeschäft. Wer das einmal in Ruhe durchsprechen möchte, erreicht mich über sesoft.de/kontakt.
Quellen
- OpenWA, Projektseite und Dokumentation: open-wa.org
- WAHA (WhatsApp HTTP API), Preise und Tiers: waha.devlike.pro
- Green API, Preisübersicht 2026: green-api.com
- WhatsApp Business API, Kostenüberblick 2026 (ChatMaxima, Chatarmin, Achiya Automation), abgerufen Juni 2026
Über den Autor
Sönke Schäfer ist selbstständiger IT-Berater und Datenarchitekt in Ostholstein und entwickelt seit über 25 Jahren Datenbank-Anwendungen für den norddeutschen Mittelstand. Sein Schwerpunkt liegt auf Microsoft Access, VBA und SQL Server sowie auf der pragmatischen Anbindung gewachsener Bestandssysteme an Schnittstellen nach außen, von WordPress über Webshops bis zu REST-APIs wie der hier beschriebenen.
