Ai Keeper/Guides/Extensions, MCP, and channels
← All workflows
Collection 08 · Tools and conversations

Extensions, MCP, and channels

Install reviewed packages, plugins, MCP servers, and skills; connect messaging sources; and control who may trigger replies or broadcasts.

34 workflowsBeginner-first

Find one workflow

Filter this collection by name, outcome, provider, engine, channel, mode, or command.

34 shown
Workflow 01

Install a ClawHub package

Review trust and capabilities before adding a curated extension bundle.

Intermediate5–15 minResult · The package is installed and healthy✓ Source-audited workflow
Current Extensions Installed tab with Marketplace and Diagnostics cards.
Installed is the health overview you return to after any package install.
Before you start
  • Internet access.
  • A specific capability you need.

  1. Open Download > ClawHub and search by outcome, not by installing a large bundle at random.

  2. Open the package and review publisher, version, trust signals, files, permissions, dependencies, and contributed capabilities.

  3. Install. Resolve only the package's stated requirements.

  4. Open Extensions > Installed, select the package, and check runtime health.

  5. Test its smallest non-destructive capability before granting broader tool access.

You are done when
Installed shows a healthy version and the expected capability appears where documented.
If something looks wrong
Package asks for more access than its job needsDo not install or keep it disabled until you understand and accept the scope.
Update breaks healthUse Repair or the package's reviewed version policy rather than deleting unrelated app state.
Workflow 02

Install, configure, update, or remove a plugin

Treat in-process plugins as higher-trust code and verify their contributed surfaces.

Advanced10–20 minResult · Plugin lifecycle state matches intent✓ Source-audited workflow
Current Extensions Installed tab with Marketplace, Providers, Channels, Services, Approvals, and Diagnostics cards.
Installed is the health overview; use Channels, Plugins, and MCP tabs for configuration.
Before you start
  • A trusted plugin source.
  • Awareness that plugins run inside the app process.

  1. Discover/install the plugin through its supported package path, then open Extensions > Plugins.

  2. Review its identity, version, lifecycle state, contributed UI/tools/services, and configuration requirements.

  3. Configure secrets through the Secrets store and enable only after review.

  4. Test one contributed capability. For updates, read changes and re-test; for removal, disable first and check dependents.

You are done when
The plugin is enabled only when healthy, its capability works, and disabling/removing it makes that capability unavailable without harming unrelated extensions.
If something looks wrong
Confusing plugin with skillSkills are instructions; plugins are executable in-process code and need more trust.
Dependent mode breaksCheck Work Mode/package requirements before uninstalling.
Workflow 03

Install an MCP server from a registry

Add external tools/resources through Model Context Protocol and inspect what is actually discovered.

Intermediate10–20 minResult · MCP handshake and discovery succeed✓ Source-audited workflow
Current Extensions hub; MCP is one of its tabs.
Registry installs land here, where you can confirm the server actually came up.
Before you start
  • A known MCP server from the official/Smithery registry.
  • Any required account or API credentials.

  1. Open Download > MCP, search the registry, and inspect transport, command/URL, publisher, and requested configuration.

  2. Install the server. Put secrets in the protected fields/Secrets store, not inline in command arguments when a reference is supported.

  3. Open Extensions > MCP, enable the server, and connect.

  4. Inspect discovered tools and resources page by page. Keep only the server roots and tools the workflow needs.

  5. Call one read-only tool from a test Chat.

You are done when
The server shows connected, protocol handshake completes, tools/resources are listed, and one read-only call returns data.
If something looks wrong
Server connects but no toolsIt may expose resources only, need configuration, or have failed pagination. Inspect its logs and capability list.
Tool can access broad filesNarrow the MCP roots; the central roots gate is a safety boundary.
Workflow 04

Add a local stdio MCP server

Configure a process-backed MCP server with an exact executable, arguments, environment, and allowed roots.

Advanced15–30 minResult · Local MCP process connects✓ Source-audited workflow
Extensions Installed with the MCP destination visible in the top navigation.
Add and diagnose local stdio servers from MCP, then return to Installed for overall health.
Before you start
  • The server's executable is installed.
  • Its current launch documentation and required environment.

  1. Open Extensions > MCP and create a local/stdio server.

  2. Enter the exact executable and argument list. Avoid wrapping an ordinary server in an unrestricted shell command.

  3. Add required environment values through protected configuration. Select the minimum filesystem roots.

  4. Save and connect. Inspect startup logs for a clean JSON-RPC initialization rather than human-readable output on stdout.

  5. List tools/resources and test one read-only operation.

You are done when
The stdio process stays running, initializes with the supported MCP revision, and returns a valid tool/resource list.
If something looks wrong
Framing/JSON parse errorsThe server may be printing banners to stdout. MCP stdout must remain protocol data; diagnostics belong on stderr.
Executable not foundUse the resolved absolute executable or configure its managed dependency instead of assuming an interactive shell PATH.
Workflow 05

Add a hosted MCP server

Connect to an HTTP/SSE/streamable endpoint and keep authentication scoped to that server.

Advanced10–20 minResult · Hosted MCP resources are reachable✓ Source-audited workflow
Extensions Installed with the MCP tool-server destination visible.
Remote MCP servers use the same MCP inventory but require a reviewed URL and authentication.
Before you start
  • A trusted HTTPS MCP endpoint.
  • Its authentication method.

  1. Create a hosted MCP entry under Extensions > MCP.

  2. Enter the exact endpoint and supported transport. Prefer HTTPS and verify the host.

  3. Store the token/credential in Secrets and attach it to this server only.

  4. Connect, inspect the negotiated capabilities, then list all pages of tools/resources.

  5. Test a read-only call and inspect System > Requests/Audit Trail.

You are done when
Authentication succeeds, discovery completes, and the audit trail attributes calls to the correct hosted server.
If something looks wrong
TLS or auth failureDo not disable verification. Correct the endpoint, certificate trust, header, or token.
Unknown server asks for local rootsReject the request unless the workflow explicitly needs and justifies that access.
Workflow 06

Let Claude Desktop or Cursor drive Ai Keeper (MCP server mode)

Point an external MCP host at Ai Keeper so it can use this Mac's chat, tools, memory, canvas, and skills — the reverse of the three workflows above.

Advanced15–25 minResult · An external MCP host lists Ai Keeper's tools✓ docs/MCP.md + MCPSettingsSection labels verified
Extensions Installed showing MCP and Diagnostics entry points.
Server-mode MCP setup starts under MCP; confirm health here before connecting another desktop client.
Before you start
  • At least one Ready model, so a tool call has something to run on.
  • An MCP host you control: Claude Desktop, Cursor, Zed, or your own script.
  • Both ends on this Mac for the first test. Only expose the endpoint beyond localhost after the remote-access workflow.

  1. Understand which direction this is. The other MCP workflows let Ai Keeper use someone else's tools. This one lets someone else use Ai Keeper's — chat, tools, memory, canvas, and skills, through one endpoint.

    The server runs inside the same process as the proxy, so anything you can do in the UI can be driven over MCP.

  2. Open System > Settings > Connection and find the Model Context Protocol card. Its own subtitle says every toggle is disabled by default — that is deliberate.

  3. Expand Connection details and read the MCP endpoint and Server-sent events rows. Use Copy connection info to put the whole thing on the clipboard as JSON rather than retyping it.

  4. Check the endpoint answers before touching your MCP host's config. A JSON-RPC result — not a connection error — means the server is live.

    Replace 11434 with your real proxy port if you changed it — the MCP endpoint rides on the proxy port, not a separate one.

    curl -sS -X POST http://127.0.0.1:11434/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize",
       "params":{"protocolVersion":"2025-03-26",
                 "capabilities":{},
                 "clientInfo":{"name":"curl","version":"0.1"}}}'
    shell

  5. Add Ai Keeper to Claude Desktop's MCP config, then restart it.

    {
  "mcpServers": {
    "aikeeper": {
      "type": "http",
      "url": "http://localhost:11434/mcp"
    }
  }
}
    json

  6. For Cursor, give it the events stream as well so server-initiated notifications arrive.

    Resource subscriptions only work over the SSE transport. POST-only clients still work, they just never get notified of changes.

    {
  "mcp.servers": {
    "aikeeper": {
      "url": "http://localhost:11434/mcp",
      "events": "http://localhost:11434/mcp/events"
    }
  }
}
    json

  7. In the host, list the tools it discovered and run one harmless read-only call. Then confirm it in System > Requests and the Audit Trail.

  8. Only now decide about the optional toggles. Require OAuth 2.1 for MCP HTTP clients is the one to turn on before this endpoint is reachable by anything but this Mac.

    Turning OAuth on without registering a client first makes every call return 401 — register the client, or leave it off while you are local-only.

You are done when
The external host lists Ai Keeper's tools, one read-only call returns a result, and the call appears in System > Requests attributed to the MCP route.
If something looks wrong
-32600 invalid request: session expiredEvery request after initialize must echo back the Mcp-Session-Id header the server returned. Simple curl scripts that start fresh each call hit this — persist the header, or re-initialize.
401 with WWW-Authenticate: BearerOAuth enforcement is on but no client is registered. Register one, or turn the toggle back off for local-only use.
resources/subscribe seems ignoredSubscriptions need the SSE transport. Confirm the host is connected to /mcp/events and that the resource URI matches case-for-case.
A long tool call reports no progressExpected. Progress and cancellation notifications are not emitted on any transport; a long call reports nothing until it returns.
Workflow 07

Add a Slack, Discord, Matrix, IRC, or other catalog connector

Configure one of the native/experimental shared-inbox sources and prove one message arrives.

Intermediate10–30 minResult · A connector is healthy and receives a test message✓ Source-audited workflow
Extensions Channels showing Catalog, Inbox, Telegram, WebChat, reply controls, and Add Connector.
Use Add Connector for a catalog source; its traffic appears in the shared Inbox after it starts.
Before you start
  • A bot/token/webhook or server account for the platform.
  • Permission to connect the selected workspace/channel.

  1. Open Extensions > Channels > Catalog and choose Slack, Discord, Twitch, IRC, Mattermost, Nextcloud Talk, WhatsApp, Matrix, or WebChat.

  2. Read its readiness, setup path, supported transport, data scopes, and memory behavior. Click Add Connector.

  3. Enter server/workspace/channel identifiers, select polling/webhook/stream/local as supported, and store credentials securely.

  4. Enable the connector and send one harmless message in the source platform.

  5. Open Extensions > Channels > Inbox and filter by the new source.

You are done when
The connector health is running and the test message appears once with the correct sender and source.
If something looks wrong
WhatsApp marked ExperimentalTreat readiness labels seriously and keep personal-message retention opt-in.
Duplicate messagesCheck polling cursor/webhook duplication before enabling auto-reply.
Workflow 08

Connect a Telegram bot

Set up the dedicated Telegram relay and restrict who may use it.

Intermediate10–20 minResult · An allowed Telegram DM reaches Ai Keeper✓ Source-audited workflow
Extensions Channels showing Telegram status and the Telegram configuration destination.
Telegram is built in but stopped by default; configure the bot before pressing Start.
Before you start
  • A bot token from BotFather.
  • The numeric user/chat IDs you intend to allow.

  1. Open Extensions > Channels > Telegram.

  2. Store the bot token through the protected field and start/verify the relay.

  3. Open DM Access and pair/allow only your test sender before enabling Auto-Reply.

  4. Send a test DM to the bot. Check Telegram status and the shared Inbox.

  5. Enable reply behavior only after inbound identity and threading are correct.

You are done when
The allowed sender's message appears and receives at most one reply; an unpaired sender is blocked by policy.
If something looks wrong
Bot token pasted into chatRevoke it in BotFather and store the replacement in Secrets.
Everyone can DM the botDisable auto-reply until DM Access is configured.
Workflow 09

Enable and test WebChat

Offer a local web conversation surface and control host, auth, and reply behavior.

Intermediate10–20 minResult · A browser message appears in Inbox✓ Source-audited workflow
Extensions Channels with WebChat available in the channel navigation.
WebChat is configured separately but its conversations arrive in the same Inbox.
Before you start
  • A Ready chat route.
  • For network exposure, a deliberate Remote Access and authentication plan.

  1. Open Extensions > Channels > WebChat and enable the local widget/service.

  2. Keep it loopback-only for the first test. Configure the model and session behavior.

  3. Open the displayed local URL in a browser and send a harmless message.

  4. Confirm it appears under Inbox and the browser receives a reply.

  5. If exposing beyond the Mac, stop and complete Remote Access, authentication, and firewall review first.

You are done when
One browser session creates one threaded conversation and messages round-trip through the selected route.
If something looks wrong
Bound to 0.0.0.0 without authReturn to loopback immediately. Network listening must be paired with authentication and firewall controls.
Workflow 10

Configure Auto-Reply and DM Access

Decide which senders can trigger the model and what reply rules apply.

Advanced10–20 minResult · Allowed senders get replies; others do not✓ Source-audited workflow
Extensions Channels showing Auto-Reply and DM Access beside the shared Inbox.
Treat reply rules and sender access as separate checks before enabling unattended responses.
Before you start
  • A connector that reliably receives one message once.
  • A known test sender.

  1. Open Extensions > Channels > DM Access and add/pair the known sender identity.

  2. Open Auto-Reply, choose the connector/account, routing model/agent, mention/DM rules, cooldown, and safe tool policy.

  3. Keep channel-send, command, file-write, and external actions approval-gated.

  4. Send one message from the allowed identity and one from an unpaired test identity.

  5. Inspect Inbox, health, and Audit Trail.

You are done when
The allowed message routes to one response; the unpaired identity receives no model-triggered response or the configured safe denial.
If something looks wrong
Reply loop between botsAdd bot/self-message filtering and cooldown before enabling in a shared room.
Identity differs across platformsUse identity links deliberately; never assume matching display names are the same person.
Workflow 11

Broadcast through multiple accounts or locations

Route an outbound message to reviewed targets without mixing account, tenant, or geographic context.

Advanced15–30 minResult · A test broadcast reaches only selected targets✓ Source-audited workflow
Extensions Channels showing Broadcast, Accounts, and Locations controls.
Configure accounts and location routing before attempting a multi-destination broadcast.
Before you start
  • Healthy outbound-capable connectors.
  • Permission from recipients and a non-sensitive test message.

  1. Open Extensions > Channels > Accounts and label each connector account clearly.

  2. Use Locations to define any location-aware routing only when the workflow needs it.

  3. Open Broadcast, choose explicit accounts/recipients, and preview the final target list.

  4. Send a harmless test to a small target set. Do not use all accounts for the first run.

  5. Inspect per-target delivery results and audit entries.

You are done when
Only the previewed recipients receive the message, with each delivery attributed to the intended account.
If something looks wrong
Wrong tenant/accountUse distinctive labels and always preview. Multi-account convenience increases the cost of a routing mistake.
Partial failureRetry only failed targets and preserve idempotency; do not resend the whole broadcast blindly.
Workflow 12

Connect Slack

Set up the native Slack route over polling or webhook, test the smallest safe scope, and keep direct messages approval-gated.

Intermediate10–30 minResult · Slack passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Bot token; webhook verification where used
  • A disposable Slack test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Slack. Choose Polling or webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Channels, threads, and mentions.

  3. Keep the connector disabled until its built-in connection test accepts the server, token, and destination.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Slack connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Slack reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredCheck platform delivery logs, pairing/allowlist policy, signature verification, and connector health.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 13

Connect Discord

Set up the native Discord route over polling, test the smallest safe scope, and keep direct messages approval-gated.

Intermediate10–30 minResult · Discord passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Bot token
  • A disposable Discord test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Discord. Choose Polling only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Server channels and direct messages.

  3. Keep the connector disabled until its built-in connection test accepts the server, token, and destination.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Discord connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Discord reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredCheck platform delivery logs, pairing/allowlist policy, signature verification, and connector health.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 14

Connect Twitch

Set up the native Twitch route over stream, test the smallest safe scope, and keep direct messages approval-gated.

Intermediate10–30 minResult · Twitch passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Twitch/IRC connection credentials
  • A disposable Twitch test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Twitch. Choose Stream only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Live chat.

  3. Keep the connector disabled until its built-in connection test accepts the server, token, and destination.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Twitch connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Twitch reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredCheck platform delivery logs, pairing/allowlist policy, signature verification, and connector health.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 15

Connect IRC

Set up the native IRC route over stream, test the smallest safe scope, and keep direct messages approval-gated.

Intermediate10–30 minResult · IRC passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Server, nickname, and channel
  • A disposable IRC test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add IRC. Choose Stream only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for IRC channels.

  3. Keep the connector disabled until its built-in connection test accepts the server, token, and destination.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper IRC connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
IRC reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredCheck platform delivery logs, pairing/allowlist policy, signature verification, and connector health.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 16

Connect Mattermost

Set up the native Mattermost route over polling, test the smallest safe scope, and keep direct messages approval-gated.

Intermediate10–30 minResult · Mattermost passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Server URL and access token
  • A disposable Mattermost test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Mattermost. Choose Polling only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Teams and channels.

  3. Keep the connector disabled until its built-in connection test accepts the server, token, and destination.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Mattermost connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Mattermost reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredCheck platform delivery logs, pairing/allowlist policy, signature verification, and connector health.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 17

Connect Nextcloud Talk

Set up the native Nextcloud Talk route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Intermediate10–30 minResult · Nextcloud Talk passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Nextcloud Talk webhook credentials
  • A disposable Nextcloud Talk test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Nextcloud Talk. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Rooms.

  3. Keep the connector disabled until its built-in connection test accepts the server, token, and destination.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Nextcloud Talk connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Nextcloud Talk reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredCheck platform delivery logs, pairing/allowlist policy, signature verification, and connector health.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 18

Connect WhatsApp

Set up the experimental WhatsApp route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · WhatsApp passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Phone number ID, verify token, and platform secret
  • A disposable WhatsApp test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add WhatsApp. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Messages and newsletters.

  3. Keep the connector disabled until its built-in connection test accepts the server, token, and destination.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper WhatsApp connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
WhatsApp reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredCheck platform delivery logs, pairing/allowlist policy, signature verification, and connector health.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 19

Connect Matrix

Set up the native Matrix route over polling, test the smallest safe scope, and keep direct messages approval-gated.

Intermediate10–30 minResult · Matrix passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Homeserver URL and access token
  • A disposable Matrix test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Matrix. Choose Polling only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Rooms.

  3. Keep the connector disabled until its built-in connection test accepts the server, token, and destination.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Matrix connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Matrix reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredCheck platform delivery logs, pairing/allowlist policy, signature verification, and connector health.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 20

Connect WebChat

Set up the native WebChat route over local, test the smallest safe scope, and keep direct messages approval-gated.

Intermediate10–30 minResult · WebChat passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Ai Keeper API authentication when exposed
  • A disposable WebChat test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add WebChat. Choose Local only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Local web conversations.

  3. Keep the connector disabled until its built-in connection test accepts the server, token, and destination.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper WebChat connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
WebChat reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredCheck platform delivery logs, pairing/allowlist policy, signature verification, and connector health.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 21

Connect Telegram

Set up the native Telegram route over bot polling, test the smallest safe scope, and keep direct messages approval-gated.

Intermediate10–30 minResult · Telegram passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Telegram bot token from BotFather
  • A disposable Telegram test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Telegram. Choose Bot polling only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Bot chats allowed by pairing and DM policy.

  3. Keep the connector disabled until its built-in connection test accepts the server, token, and destination.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Telegram connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Telegram reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredCheck platform delivery logs, pairing/allowlist policy, signature verification, and connector health.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 22

Connect Google Chat

Set up the extended Google Chat route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · Google Chat passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Google Chat webhook/bot credentials
  • A disposable Google Chat test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Google Chat. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Outbound messages; authenticated inbound bridge when available.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Google Chat connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Google Chat reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 23

Connect Signal

Set up the extended Signal route over signal-cli / rest bridge, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · Signal passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Trusted Signal bridge URL and credentials
  • A disposable Signal test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Signal. Choose signal-cli / REST bridge only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Signal messages.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Signal connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Signal reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 24

Connect BlueBubbles

Set up the extended BlueBubbles route over bluebubbles bridge, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · BlueBubbles passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • BlueBubbles server URL, password, and webhook secret
  • A disposable BlueBubbles test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add BlueBubbles. Choose BlueBubbles bridge only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for iMessage delivery through BlueBubbles.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper BlueBubbles connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
BlueBubbles reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 25

Connect iMessage

Set up the extended iMessage route over messages.app, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · iMessage passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • macOS Automation permission; authenticated mirror for inbound
  • A disposable iMessage test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add iMessage. Choose Messages.app only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Outbound Messages.app conversations.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper iMessage connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
iMessage reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 26

Connect Microsoft Teams

Set up the extended Microsoft Teams route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · Microsoft Teams passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Teams webhook/bot credentials
  • A disposable Microsoft Teams test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Microsoft Teams. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Teams conversations.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Microsoft Teams connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Microsoft Teams reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 27

Connect Feishu / Lark

Set up the extended Feishu / Lark route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · Feishu / Lark passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Feishu/Lark app credentials and signing secret
  • A disposable Feishu / Lark test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Feishu / Lark. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Chats and groups.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Feishu / Lark connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Feishu / Lark reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 28

Connect LINE

Set up the extended LINE route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · LINE passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • LINE channel token and signing secret
  • A disposable LINE test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add LINE. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for LINE conversations.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper LINE connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
LINE reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 29

Connect Nostr

Set up the extended Nostr route over relay, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · Nostr passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Relay URL and reviewed signing identity
  • A disposable Nostr test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Nostr. Choose Relay only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Relay-backed publishing.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Nostr connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Nostr reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 30

Connect Synology Chat

Set up the extended Synology Chat route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · Synology Chat passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Synology Chat webhook credentials
  • A disposable Synology Chat test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Synology Chat. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Synology Chat messages.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Synology Chat connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Synology Chat reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 31

Connect Tlon / Urbit

Set up the extended Tlon / Urbit route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · Tlon / Urbit passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Tlon/Urbit bridge credentials
  • A disposable Tlon / Urbit test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Tlon / Urbit. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Tlon conversations.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Tlon / Urbit connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Tlon / Urbit reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 32

Connect Zalo

Set up the extended Zalo route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · Zalo passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • Zalo app credentials and signing secret
  • A disposable Zalo test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add Zalo. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for Zalo conversations.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper Zalo connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
Zalo reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 33

Connect QQ Bot

Set up the extended QQ Bot route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · QQ Bot passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • QQ Bot credentials and signing secret
  • A disposable QQ Bot test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add QQ Bot. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for QQ conversations.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper QQ Bot connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
QQ Bot reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.
Workflow 34

Connect WeChat

Set up the extended WeChat route over webhook, test the smallest safe scope, and keep direct messages approval-gated.

Advanced10–30 minResult · WeChat passes a controlled message test✓ Channel source catalog and Extensions navigation verified
Before you start
  • WeChat app credentials and signing secret
  • A disposable WeChat test conversation or destination.
  • A Ready model/provider route if Auto-Reply will be tested.

  1. Open Extensions > Channels and add WeChat. Choose Webhook only when it matches the account/bridge you prepared.

  2. Save credentials through the channel secret fields or Secret Store. Grant only the minimum scope needed for WeChat conversations.

  3. For an extended webhook connector, start with outbound-only testing. Do not enable unsigned inbound delivery; an authenticated bridge and platform signature check are required.

  4. Enable the connector, set DM Access to pairing or an explicit allowlist, and leave Auto-Reply off for the first transport test.

  5. Send Ai Keeper WeChat connection test to the disposable destination. Confirm it arrives once and inspect the connector status/inbox.

  6. Only after transport succeeds, enable Auto-Reply for the test destination, send one benign inbound message, approve pairing if requested, and turn Auto-Reply back off if it is not required.

You are done when
WeChat reports healthy, the controlled outbound message arrives once, and any accepted inbound message is authenticated and visible in the shared inbox/audit trail.
If something looks wrong
Messages duplicateUse one transport and one active account for the test; check polling interval and webhook retries.
Inbound is ignoredUnsigned extended-channel webhooks are intentionally blocked. Use an authenticated bridge/signature path; do not weaken the gate.
Bot replies to strangersDisable Auto-Reply immediately and restore pairing or an explicit allowlist.

Keep going

← AutomationPrevious collectionImages, video, voice, screen, and camera →Next collection