Skip to main content
A channel connects one expert to a bot on an IM platform, so your team chats in a familiar window instead of switching to the web app.

​
Supported platforms

QQ is not implemented. All four platforms support both QR quick setup and manual credential entry.

​
One critical premise: credits bill to the binder

A binding maps “bot → one Profy user + one expert.” When a message arrives, the system looks up the binding by the bot’s app ID and invokes as the binder.
Everyone in a group talking to that bot spends the credits of the account that bound the channel, not their own. The IM side does not identify individual senders, and there is no “link your Profy account first” flow.So before dropping a bot into a large group, be clear about whose bill it is.
If the binding is deleted, that bot’s messages are dropped and its adapter is unloaded automatically — no error is posted to the group.

​
Conversation isolation

Two people in the same group therefore have independent context and can’t see each other’s history, even though the messages share a room.

​
How replies are delivered

Replies stream out as chunked bubbles: once enough text accumulates, a bubble is sent — it doesn’t wait for the full generation. Split points avoid the middle of code blocks: inside a code fence the buffer keeps growing to the max instead of cutting a snippet in half. Tool execution posts a status notice first (“Searching…”), and delegation posts “Consulting X.”
Edit-in-place streaming (a single bubble whose content keeps refreshing) is turned off in code — both the WeCom and DingTalk adapters set that flag to false. Every platform currently uses chunked bubbles.

​
@-mentions in groups

In a group, messages that don’t mention the bot don’t trigger a reply — but they aren’t lost either. They go into a pending buffer and get merged into your next @-mention. This compensates for a Feishu constraint: you can’t attach a file and @ the bot in the same message, so “send the file, then @ with the ask” is a common pattern. The buffer is bounded: at most 10 entries and 50 MB of files per group × person, kept for 30 minutes, oldest dropped first.

​
Files and images

You can send files and images to the expert directly in IM. Each file is capped at 15 MB; larger ones are skipped (logged server-side, silently ignored on your side). Files are uploaded to object storage along the same path as web uploads. Files the expert produces are delivered back into the chat.

​
Commands

​
Feishu user authorization

Without authorization, the expert calls Feishu APIs as the bot — documents it creates belong to the bot and you may not be able to see them. /auth runs a device authorization flow: the bot sends a card, you tap the button (the code is valid for about 10 minutes by default), and documents created afterwards belong to you. Tokens refresh automatically; if the refresh token dies, it falls back to the bot identity — when a tool reports a permission error, run /auth again.

​
Billing and trials

  • Usage settles against the binder’s account, with the same rules as the web app
  • Trial turns are shared between IM and web (same expert, same account)
  • When trials run out, IM returns an error message with the web purchase link for that expert (there’s no purchase UI in IM)
  • A proactive notice fires after the last free trial turn, so the next message doesn’t hit a wall unannounced

​
What IM can’t do

​
Failures and fixes

​
Per-platform guides

Feishu

Setup steps and OAuth

DingTalk

DingTalk bot configuration

WeCom

WeCom app configuration

WeChat

WeChat official account setup