Chatwoot restricts free cloud API access, pushing users to self-hosting

On 16 July 2026, Chatwoot announced a significant change to its cloud hosting pricing structure, removing API and webhook access from its free tier. This move effectively forces developers and small teams who rely on programmatic integrations to either upgrade to a paid plan or migrate to a self-hosted deployment. The company cited infrastructure costs and abuse by spammers as the primary drivers for this policy shift, while confirming that the open-source Community Edition remains fully functional with all integration capabilities intact.

What happened

The change impacts both new and existing users of Chatwoot Cloud. New accounts created on the free "Hacker" plan no longer receive any API access. Existing free accounts were given a two-week transition period before their API tokens stopped working for account-scoped requests. Users reported that their authentication tokens still returned valid profile data, but any attempt to access account-specific resources resulted in a 403 error stating that API access was not enabled. This behavior often mimics a broken token, causing confusion until users realize the restriction is tied to their subscription level rather than technical failure.

In response, many technical teams are evaluating self-hosting options. The Chatwoot Community Edition is licensed under MIT, allowing unrestricted use of the core platform, including APIs, webhooks, live chat, and automation features. However, users must distinguish between the standard Docker image, which includes enterprise-only code, and the Community Edition image tagged with -ce. Using the correct image ensures compliance with the open-source license while avoiding unintended usage of proprietary features like custom dashboards or AI assistants that require a paid subscription.

Key details

• Policy change date: 16 July 2026 marked the removal of API and webhook access for free cloud accounts.
• Affected plans: The "Hacker" (free) plan now limits users to 2 agents, 500 conversations per month, and 30 days of data retention without API access.
• Self-hosted alternative: The Community Edition image (chatwoot/chatwoot:v4.18.0-ce) retains full API and webhook functionality under the MIT license.
• Resource requirements: A minimal self-hosted setup idles at approximately 810 MB of RAM, requiring at least 2 GB of total system memory for stable operation.
• Cost comparison: Paid cloud plans start at $19 per agent per month, whereas self-hosting costs are limited to server infrastructure, such as a €7.50 monthly VPS configuration.
• Enterprise features: Self-hosted users lose access to SLA management, audit logs, and the Captain AI assistant unless they purchase an enterprise license.

Background

Chatwoot is an open-source customer engagement suite that provides live chat, email, and social media messaging capabilities. Like many modern SaaS products, it relies heavily on APIs and webhooks to integrate with other tools, such as CRM systems, help desks, and custom internal applications. Webhooks allow the platform to send real-time notifications about new messages or status changes to external servers, while APIs enable programs to read and write data within Chatwoot.

The distinction between the "Community" and "Enterprise" editions is critical for self-hosters. The Community Edition contains only MIT-licensed code, which is free to use and modify. The standard Docker image often includes additional code from the enterprise/ directory, which is governed by a separate commercial license. While the software will run, using these enterprise features in production without a paid subscription violates the terms. Therefore, administrators must explicitly pin their Docker images to the -ce tag to ensure they are running only the open-source components.

Why it matters

For teams that have built custom workflows around Chatwoot’s free cloud tier, this change breaks existing integrations immediately. Automation scripts, notification bots, and data synchronization tools that depend on webhooks or API calls will fail silently or return permission errors. This disruption highlights the risk of relying on free tiers of managed services for critical business logic. When a provider changes its pricing model, the cost of migration can far exceed the previous savings, especially if the team lacks DevOps experience.

Self-hosting offers a path to regain control over these integrations, but it introduces operational overhead. Teams must manage database migrations, handle security updates, and ensure high availability. The requirement for specific dependencies like PostgreSQL with the pgvector extension and Redis adds complexity to the deployment process. However, for organizations with two or more agents, the fixed cost of a virtual private server is often lower than the per-agent pricing of cloud plans, making self-hosting financially attractive despite the maintenance burden.

What you can do

• Audit your current plan: Check if your Chatwoot Cloud account is on the free tier and verify if your integrations are currently failing with 403 errors.
• Switch to the CE image: If self-hosting, update your Docker Compose file to use chatwoot/chatwoot:v4.18.0-ce to ensure you are using only MIT-licensed code.
• Verify resource allocation: Ensure your server has at least 2 GB of RAM to accommodate the Rails server, Sidekiq worker, PostgreSQL, and Redis processes.
• Configure environment variables correctly: Generate a unique SECRET_KEY_BASE and set FRONTEND_URL to your public HTTPS address to avoid session and redirect issues.
• Set up a reverse proxy: Use a tool like Caddy or Nginx to handle TLS termination and WebSocket upgrades, as the Rails application listens only on localhost.
• Test API connectivity: After deployment, generate a new access token in the dashboard and verify it can retrieve conversation data via curl to confirm full API functionality.