Chat Providers Overview

profClaw’s chat provider system provides a unified abstraction across all messaging platforms. One agent, every channel.

Supported Channels

Provider	Type	Status	Key Capability
WebChat	Built-in	Stable	Zero-setup browser widget
Slack	Work	Stable	Socket Mode, Block Kit, slash commands
Discord	Community	Stable	Slash commands, components
Telegram	Messaging	Stable	Webhooks, inline buttons
WhatsApp	Messaging	Stable	WhatsApp Business API
Matrix	Open Protocol	Stable	E2EE, federated
Microsoft Teams	Work	Stable	Adaptive Cards, Bot Framework
Rocket.Chat	Self-hosted	Beta	Open-source Slack alternative
IRC	Legacy	Beta	Classic IRC protocol
Signal	Secure	Beta	E2EE, signald bridge
LINE	Asia	Beta	LINE Messaging API
Zalo	Vietnam	Beta	Zalo OA API
Viber	Messaging	Beta	Viber Bot API
Facebook Messenger	Social	Beta	Meta Messenger Platform
WeChat	China	Beta	WeChat Official Account
Tlon/Urbit	Decentralized	Experimental	Urbit network
Custom	DIY	Stable	Build your own provider
Google Chat	Work	Beta	Google Workspace
Mattermost	Self-hosted	Beta	Open-source Teams alternative
DingTalk	China	Beta	Alibaba DingTalk
WeCom	China	Beta	Tencent WeCom
Feishu/Lark	Work	Beta	ByteDance enterprise
QQ	Social	Beta	Tencent QQ
Nostr	Decentralized	Experimental	Nostr protocol
Twitch	Streaming	Beta	Twitch chat integration
Nextcloud Talk	Self-hosted	Beta	Nextcloud messaging
Synology Chat	Self-hosted	Beta	Synology NAS chat

WebChat is enabled by default with no credentials required. It is always available at http://localhost:3000. All other providers require credential setup.

Capabilities Comparison

Feature	WebChat	Slack	Discord	Telegram	WhatsApp	Teams
Direct Messages	Yes	Yes	Yes	Yes	Yes	Yes
Group/Channel	No	Yes	Yes	Yes	No	Yes
Slash Commands	No	Yes	Yes	No	No	Yes
Buttons/Menus	No	Yes	Yes	Yes	Limited	Yes
File Uploads	No	Yes	Yes	Yes	Yes	Yes
Reactions	No	Yes	Yes	No	No	No
Threads	No	Yes	Yes	No	No	Yes
Rich Blocks	No	Yes	No	No	No	Yes
E2E Encryption	No	No	No	No	Yes	No
OAuth Install	No	Yes	Yes	No	No	Yes

Multi-Account Support

profClaw supports multiple accounts per provider. Each account is independently configured and can be assigned to different channels or teams:

# settings.yml
chat:
  slack:
    accounts:
      - id: work
        bot_token: xoxb-work-...
        is_default: true
      - id: community
        bot_token: xoxb-community-...

Architecture

All providers implement the same interface, allowing the execution engine and security layer to treat all channels uniformly:

Inbound: Receive messages via webhooks or long-polling
Outbound: Send messages and structured responses
Status: Health checks and connection monitoring
Auth: OAuth flows or manual token configuration

User Message
    |
    v
[Chat Provider]  ----incoming----> [Message Handler]
                                         |
                                    [AI Executor]
                                    [Tool Pipeline]
                                         |
[Chat Provider]  <---outbound-----  [Response]

Webhook Setup

Most providers require a public HTTPS webhook URL to deliver events. Use profclaw serve to start the server, then expose it with a tunnel during development or configure your domain for production.

Development (tunnel)
Production

Use a tunnel tool to expose your local server:

# Using cloudflared (recommended, free, no account needed for quick tunnels)
brew install cloudflared
cloudflared tunnel --url http://localhost:3000

# Or using ngrok
ngrok http 3000

Use the generated HTTPS URL as your webhook base URL in the provider’s developer portal.

Set your domain as the webhook base URL:

WEBHOOK_BASE_URL=https://profclaw.yourdomain.com

profClaw appends provider-specific paths automatically. For example, the Slack webhook becomes: https://profclaw.yourdomain.com/api/webhooks/slack

All webhook endpoints validate request signatures from the provider. Never disable signature verification in production.

Configuration Pattern

All providers follow the same environment variable pattern - enable a provider by setting its credentials:

# Slack
SLACK_BOT_TOKEN=xoxb-...
SLACK_APP_TOKEN=xapp-...
SLACK_SIGNING_SECRET=...

# Discord
DISCORD_BOT_TOKEN=...

# Telegram
TELEGRAM_BOT_TOKEN=...

Providers with no credentials set are simply not loaded. There is no need to explicitly disable them.

Security Considerations

Chat providers inherit the global security mode. Restrict which channels or users the agent responds to:

chat:
  channels:
    slack:
      allowedChannels:
        - C0123456789  # #engineering
        - C9876543210  # #devops
      allowedUsers:
        - U012345678   # Specific user IDs only

Health Check

profclaw doctor --chat

Shows connection status for all configured chat providers, including last event received and any authentication errors.

Popular Guides

Slack Bot Setup

Step-by-step guide to creating a Slack app and connecting profClaw.

WhatsApp Bot

Connect profClaw to WhatsApp Business API.

Self-Hosted Deployment

Configure public webhooks for production deployments.

Custom Provider

Implement your own chat provider using the provider SDK.

profclaw channels - Enable, disable, and test chat providers from the CLI
Security Overview - Restrict which channels and users the agent responds to
profclaw tunnel - Expose your local server for webhook delivery
Configuration Overview - settings.yml reference for channel configuration

​Supported Channels

​Capabilities Comparison

​Multi-Account Support

​Architecture

​Webhook Setup

​Configuration Pattern

​Security Considerations

​Health Check

​Popular Guides

Slack Bot Setup

WhatsApp Bot

Self-Hosted Deployment

Custom Provider

​Related

Supported Channels

Capabilities Comparison

Multi-Account Support

Architecture

Webhook Setup

Configuration Pattern

Security Considerations

Health Check

Popular Guides

Related