Chatwoot schränkt kostenlosen Cloud-API-Zugang ein und drängt Nutzer zum Self-Hosting

Am 16. Juli 2026 kündigte Chatwoot eine wesentliche Änderung an seiner Preisstruktur für das Cloud-Hosting an und entfernte den API- sowie Webhook-Zugang aus der kostenlosen Stufe. Dieser Schritt zwingt Entwickler und kleine Teams, die auf programmatische Integrationen angewiesen sind, entweder auf einen kostenpflichtigen Plan zu wechseln oder auf eine selbst gehostete Bereitstellung umzuziehen. Das Unternehmen nannte Infrastrukturkosten und Missbrauch durch Spammer als Hauptgründe für diese Richtungsänderung, bestätigte jedoch gleichzeitig, dass die Open-Source Community Edition mit allen Integrationsfunktionen voll funktionsfähig bleibt.

Was passiert ist

Die Änderung betrifft sowohl neue als auch bestehende Nutzer von Chatwoot Cloud. Neue Konten, die auf dem kostenlosen „Hacker“-Plan erstellt werden, erhalten keinen API-Zugang mehr. Bestehenden kostenlosen Konten wurde eine zweiwöchige Übergangsfrist gewährt, bevor ihre API-Token für kontospezifische Anfragen nicht mehr funktionierten. Nutzer berichteten, dass ihre Authentifizierungstoken weiterhin gültige Profildaten zurückgaben, aber jeder Versuch, auf konto-spezifische Ressourcen zuzugreifen, einen 403-Fehler auslöste, der angab, dass der API-Zugang nicht aktiviert sei. Dieses Verhalten ahmt oft einen defekten Token nach und führt zu Verwirrung, bis Nutzer erkennen, dass die Einschränkung an ihr Abonnement gebunden ist und nicht auf einem technischen Fehler beruht.

Als Reaktion darauf prüfen viele technische Teams Optionen für das Self-Hosting. Die Chatwoot Community Edition ist unter der MIT-Lizenz lizenziert, was die uneingeschränkte Nutzung der Kernplattform einschließlich APIs, Webhooks, Live-Chat und Automatisierungsfunktionen ermöglicht. Nutzer müssen jedoch zwischen dem Standard-Docker-Image, das nur für Unternehmen verfügbaren Code enthält, und dem Community-Edition-Image mit dem Tag -ce unterscheiden. Die Verwendung des richtigen Images stellt die Einhaltung der Open-Source-Lizenz sicher und vermeidet die unbeabsichtigte Nutzung proprietärer Funktionen wie benutzerdefinierte Dashboards oder KI-Assistenten, die ein kostenpflichtiges Abonnement erfordern.

Wichtige Details

• Datum der Richtlinienänderung: Der 16. Juli 2026 markierte die Entfernung des API- und Webhook-Zugangs für kostenlose Cloud-Konten.
• Betroffene Pläne: Der „Hacker“-Plan (kostenlos) beschränkt Nutzer nun auf 2 Agenten, 500 Konversationen pro Monat und 30 Tage Datenspeicherung ohne API-Zugang.
• Self-Hosting-Alternative: Das Community-Edition-Image (chatwoot/chatwoot:v4.18.0-ce) behält die volle API- und Webhook-Funktionalität unter der MIT-Lizenz bei.
• Ressourcenanforderungen: Eine minimale self-hosted Installation verbraucht im Leerlauf etwa 810 MB RAM und erfordert mindestens 2 GB Gesamtspeicher für einen stabilen Betrieb.
• Kostenvergleich: Kostenpflichtige Cloud-Pläne beginnen bei 19 USD pro Agent und Monat, während die Kosten für Self-Hosting auf die Serverinfrastruktur beschränkt sind, wie z. B. eine monatliche VPS-Konfiguration für 7,50 €.
• Unternehmensfunktionen: Self-Hosted-Nutzer verlieren den Zugang zu SLA-Management, Audit-Logs und dem Captain AI Assistant, es sei denn, sie erwerben eine Enterprise-Lizenz.

Hintergrund

Chatwoot ist eine Open-Source-Suite für Kundenengagement, die Live-Chat-, E-Mail- und Social-Media-Messaging-Funktionen bietet. Wie viele moderne SaaS-Produkte verlässt sich Chatwoot stark auf APIs und Webhooks zur Integration mit anderen Tools, wie CRM-Systemen, Helpdesks und internen Anwendungen. Webhooks ermöglichen es der Plattform, Echtzeit-Benachrichtigungen über neue Nachrichten oder Statusänderungen an externe Server zu senden, während APIs Programmen das Lesen und Schreiben von Daten innerhalb von Chatwoot ermöglichen.

Die Unterscheidung zwischen den Ausgaben „Community“ und „Enterprise“ ist für Self-Hoster entscheidend. Die Community Edition enthält nur Code unter der MIT-Lizenz, der frei nutzbar und modifizierbar ist. Das Standard-Docker-Image enthält oft zusätzlichen Code aus dem Verzeichnis enterprise/, der einer separaten kommerziellen Lizenz unterliegt. Obwohl die Software läuft, verstößt die Nutzung dieser Enterprise-Funktionen in der Produktion ohne kostenpflichtiges Abonnement gegen die Bedingungen. Daher müssen Administratoren ihre Docker-Images explizit auf das Tag -ce festlegen, um sicherzustellen, dass sie nur die Open-Source-Komponenten ausführen.

Warum das wichtig ist

Für Teams, die benutzerdefinierte Workflows rund um die kostenlose Cloud-Stufe von Chatwoot aufgebaut haben, bricht diese Änderung bestehende Integrationen sofort. Automatisierungsskripte, Benachrichtigungs-Bots und Datensynchronisierungstools, die von Webhooks oder API-Aufrufen abhängen, schlagen still fehl oder geben Berechtigungsfehler zurück. Diese Störung verdeutlicht das Risiko, sich bei kritischer Geschäftslogik auf kostenlose Stufen verwalteter Dienste zu verlassen. Wenn ein Anbieter sein Preismodell ändert, können die Migrationskosten die bisherigen Einsparungen weit übersteigen, insbesondere wenn dem Team DevOps-Erfahrung fehlt.

Self-Hosting bietet einen Weg, die Kontrolle über diese Integrationen wiederzuerlangen, bringt jedoch operativen Aufwand mit sich. Teams müssen Datenbankmigrationen verwalten, Sicherheitsupdates durchführen und Hochverfügbarkeit sicherstellen. Die Anforderung spezifischer Abhängigkeiten wie PostgreSQL mit der Erweiterung pgvector und Redis erhöht die Komplexität des Bereitstellungsprozesses. Für Organisationen mit zwei oder mehr Agenten sind die festen Kosten eines virtuellen privaten Servers jedoch oft niedriger als die pro-Agent-Preise der Cloud-Pläne, was Self-Hosting trotz des Wartungsaufwands finanziell attraktiv macht.

Was Sie tun können

• Überprüfen Sie Ihren aktuellen Plan: Prüfen Sie, ob Ihr Chatwoot Cloud-Konto sich in der kostenlosen Stufe befindet, und verifizieren Sie, ob Ihre Integrationen derzeit mit 403-Fehlern scheitern.
• Wechseln Sie zum CE-Image: Wenn Sie self-hosten, aktualisieren Sie Ihre Docker Compose Datei, um chatwoot/chatwoot:v4.18.0-ce zu verwenden, damit Sie sicherstellen, dass Sie nur Code unter der MIT-Lizenz nutzen.
• Überprüfen Sie die Ressourcenzuweisung: Stellen Sie sicher, dass Ihr Server über mindestens 2 GB RAM verfügt, um die Prozesse für Rails-Server, Sidekiq-Worker, PostgreSQL und Redis unterzubringen.
• Konfigurieren Sie Umgebungsvariablen korrekt: Generieren Sie einen eindeutigen SECRET_KEY_BASE und setzen Sie FRONTEND_URL auf Ihre öffentliche HTTPS-Adresse, um Sitzungs- und Weiterleitungsprobleme zu vermeiden.
• Richten Sie einen Reverse Proxy ein: Verwenden Sie ein Tool wie Caddy oder Nginx, um TLS-Terminierung und WebSocket-Upgrades zu handhaben, da die Rails-Anwendung nur auf localhost lauscht.
• Testen Sie die API-Verbindung: Nach der Bereitstellung generieren Sie ein neues Zugriffstoken im Dashboard und überprüfen Sie, ob es Konversationsdaten über curl abrufen kann, um die volle API-Funktionalität zu bestätigen.