Skip to main content

Channel Guides

Loong currently exposes 29 cataloged channel surfaces. Of those, 26 are already actionable public surfaces: 6 gateway-supervised service channels, 2 standalone native-serve surfaces, 15 config-backed outbound surfaces, and 3 external plugin-backed bridge surfaces. The remaining 3 surfaces stay catalog-only planned entries. Several gateway-supervised or standalone service lanes still report implementation_status=plugin_backed in inventory because the catalog preserves managed-bridge-capable setup contracts; this hub keeps that distinction visible instead of flattening it away. Use Channels when you still need the conceptual model first. Use this hub when you already know the surface and want the exact config, command, and support boundary for that one channel. Keep Channel Recipes for representative rollout patterns rather than the full channel inventory.

Quick Picks

Use this short list when you want a practical starting point before scanning the full surface matrix below.
If you want…Start hereWhy
a primary team-chat runtimeFeishu/Larkwebhook and websocket paths are both documented on the most feature-rich managed-bridge-capable service channel
the lightest reply-loop botTelegramit remains the smallest managed-bridge-capable service setup path
a Cloud API plus webhook runtimeWhatsAppsend and serve are both shipped on the same managed-bridge-capable service surface
the official enterprise AIBot laneWeComthe public docs keep the long-connection contract explicit while surfacing its managed-bridge-capable service model
a WeChat or personal WhatsApp bridge-first laneWeixin, OneBot, or WhatsApp Personalplugin-backed bridge surfaces stay visible and actionable instead of being flattened into placeholders
an official QQ runtime laneQQ BotLoong now owns the native QQ gateway runtime directly
one operator-owned inbound webhook edge or one-way governed deliveryWebhook or EmailWebhook now covers the standalone native-serve lane, while Email remains a clean outbound-only example

Gateway-Supervised Service Surfaces

These are the shipped send plus serve lanes that can currently join the daemon-owned gateway owner contract. Some still keep implementation_status=plugin_backed in the catalog because their setup and transport metadata preserve managed-bridge-capable history.
SurfaceTransportSendServe
Feishu/Larkfeishu_openapi_webhook_or_websocketchannels send feishuchannels serve feishu
Telegramtelegram_bot_api_pollingchannels send telegramchannels serve telegram
Matrixmatrix_client_server_syncchannels send matrixchannels serve matrix
QQ Botqq_official_bot_gateway_or_plugin_bridgechannels send qqbotchannels serve qqbot
WhatsAppwhatsapp_cloud_apichannels send whatsappchannels serve whatsapp
WeComwecom_aibot_long_connectionchannels send wecomchannels serve wecom

Standalone Native-Serve Surfaces

These surfaces ship send plus serve today, but their built-in runtime still stays on the direct channels serve <surface> command instead of gateway supervision.
SurfaceTransportSendServeRuntime owner
LINEline_messaging_apichannels send linechannels serve linestandalone native serve
Webhookgeneric_webhookchannels send webhookchannels serve webhookstandalone native serve

External Plugin-Backed Bridge Surfaces

These surfaces are already real Loong channel contracts, but the active runtime is owned by an external bridge or managed plugin rather than a built-in channels serve <surface> loop.
SurfaceTransportCurrent operator pathRuntime owner
Weixinwechat_clawbot_ilink_bridgerun loong weixin onboard, then verify with loong doctor / loong channelsexternal plugin
OneBotonebot_v11_bridgeconfigure bridge contract + run loong doctor / loong channelsexternal plugin
WhatsApp Personalwhatsapp_web_baileys_bridgerun the bundled QR bridge, then use loong doctor / loong channels / grouped send/serveexternal plugin

Config-Backed Outbound Surfaces

These surfaces ship direct sends today and keep serve in the catalog without overclaiming a reply-loop runtime.
SurfaceTransportSendServe status
Discorddiscord_http_apichannels send discordoutbound-only
Slackslack_web_apichannels send slackoutbound-only
DingTalkdingtalk_custom_robot_webhookchannels send dingtalkoutbound-only
Emailsmtp_imapchannels send emailoutbound-only
Google Chatgoogle_chat_incoming_webhookchannels send google-chatoutbound-only
Signalsignal_cli_rest_apichannels send signaloutbound-only
Twitchtwitch_chat_apichannels send twitchoutbound-only
Microsoft Teamsmicrosoft_teams_incoming_webhookchannels send teamsoutbound-only
Mattermostmattermost_rest_apichannels send mattermostoutbound-only
Nextcloud Talknextcloud_talk_bot_apichannels send nextcloud-talkoutbound-only
Synology Chatsynology_chat_outgoing_incoming_webhookschannels send synology-chatoutbound-only
IRCirc_socketchannels send ircoutbound-only
iMessageimessage_bridge_apichannels send imessageoutbound-only
Nostrnostr_relayschannels send nostroutbound-only
Tlontlon_urbit_ship_apichannels send tlonoutbound-only

Catalog-Only Planned Surfaces

These surfaces stay visible in the internal registry, but they are not yet public setup lanes and should not be marketed as shipped runtimes.
SurfaceRegistry role
Zaloplanned official-account surface
Zalo Personalplanned personal bridge surface
WebChatplanned embedded web inbox surface

Reading Rule

  • Start with Channels when you still need to choose between gateway-supervised, standalone native-serve, plugin-backed, and outbound-only delivery.
  • Use an individual guide page when the surface is already decided and you need the exact config and smoke-test path.
  • Plugin-backed guides are the right next stop when the transport is real but Loong intentionally leaves upstream login and listener ownership to an external bridge.
  • Keep Channel Recipes for representative rollout paths instead of the full surface inventory.
  • Keep Gateway And Supervision open whenever the chosen surface is gateway-supervised and needs long-lived ownership.