Tool integrations
Tool integrations let you connect your own account with an outside service — your GitHub account, for example — so a bot can act as you when you ask it to. You connect the account once, and you stay in control of which conversations may use it and how much of a result is allowed to appear there.
Tool integrations (this page, under Integrations in the sidebar) connect your personal accounts so bots can use them. A bot's Integrations tab connects the bot to a messaging platform like Telegram or email. Different feature, similar name.
Availability
Tool integrations are off unless your deployment turns them on, and they are off by default. While they are off, the whole feature returns "not enabled" — there is no partially-working state, and no connection can be made.
If the Integrations page is missing or reports that integrations are not enabled, the feature has not been switched on for your deployment. Ask whoever administers it; there is nothing to configure on your side.
Which services you can connect is also controlled centrally. A service becomes connectable only after your operator registers it, so the Browse tab reflects what your deployment has set up rather than a catalogue of everything that theoretically exists. Today the only connectable service is GitHub. Other entries may appear in Browse for discovery before they are connectable.
How your data is handled
This is the part worth understanding before you connect anything.
When a bot uses one of your connected tools, the tool does not run inside the chat service. It runs in a separate, isolated service that has no route to the main database and no general access to the internet. The full result stays there. What reaches the conversation is only what your own rules allow — and if your rules allow nothing, the tool still runs and the result is simply destroyed without ever leaving.
Three consequences worth knowing:
- In a direct message with a bot, you get the full result. It is your account, your data, and your conversation.
- In a group, nothing is shared until you have said it may be. The default is to share nothing.
- A result you never approve is not stored anywhere. Pending results live only in the isolated service and expire on their own, typically within an hour.
Your access tokens for the connected service are never shown to you, never stored by the chat application, and never written to logs. Revoking a connection is always available to you.
The Integrations page
Open Integrations from the web app. It has five tabs.
| Tab | What it is for |
|---|---|
| Browse | See what you can connect, and connect it |
| Connections | See what you have connected; revoke any of it |
| Group access | Decide which groups may use your tools, and how much they may see |
| Pending | Approve or reject results that are waiting on you |
| History | Review results that were approved |
Connecting an account
- Go to Browse and find the service.
- Click Connect. You are sent to that service's own sign-in and permission screen.
- Approve the access it asks for. You are returned to the Integrations page with a confirmation banner.
The connection may take a moment to appear under Connections. If you connect something you had already connected, you will be told so rather than being made to do it twice.
If something goes wrong, the banner says at which stage it failed. The usual cause is closing the provider's window before approving.
Reviewing and revoking
Connections lists what you have connected and the permissions each grant carries. Revoking is immediate and needs a confirmation click, because it takes effect for every bot and every group at once. You can reconnect afterwards.
You only ever see and manage your own connections. Nobody else's are visible to you, including administrators.
Group access
By default, a group may not use your connected tools at all. Group access is something you grant, per group, from the Group access tab.
Each rule combines two decisions.
First — may the group use it?
| Setting | Effect |
|---|---|
| Not allowed | The tool cannot be used on your behalf in that group |
| Ask me first | The tool runs, the result waits in Pending, and nothing appears until you approve it |
| Always allowed | The tool runs and the result is shared automatically, in the form you chose below |
Second — how much of the result may the group see?
| Setting | What the group sees |
|---|---|
| Full | The complete result |
| Summarized | A summary instead of the contents |
| Redacted | The shape of the result — which fields came back — with the values removed |
| Nothing | The tool runs, but no part of the result is shared |
Rules can be as broad or as narrow as you like: all tools in a group, everything from one service, or one specific tool. The most specific rule wins, so you can allow a service broadly and still single out one tool for tighter handling.
Two behaviours to expect:
- If a conversation belongs to more than one group, the most restrictive rule applies. A "not allowed" anywhere wins over an "always allowed" elsewhere.
- If no rule matches, the answer is no. Absence of a rule is never taken as permission.
You govern your own tools. The rules you write are always about your connected accounts, and nobody can write rules on your behalf.
Pending approvals
When a rule says Ask me first, the result waits in Pending.
What you see there is deliberately not the result. You get the tool's name, when it ran, which conversation asked, which rule applied, how large the result is, and a structural outline of it — "object with 4 fields: name, owner, stars, private". Field names are shown; their values are not. That is enough to decide without the contents reaching the page before you have decided.
- Approve releases it, and you choose the form — full, summarized, or redacted.
- Reject destroys it unread.
Pending results expire on their own. If one has been sitting long enough to expire, approving it will report that it is no longer there; ask for it again.
History
History shows results that were approved, newest first, with which form was released, whether it succeeded, which conversation it came from, and how long it took.
Only approved results appear. Rejected and expired ones were destroyed and leave no content behind.
Optional: your own summarization model
If you want Summarized releases written by a model you control rather than by the deployment's default behaviour, you can register a personal model key. The Integrations page reports whether you have one, along with which endpoint and model it would be used with.
Registering one is done through the API keys endpoint with a personal (user) scope — there is no screen for it in the web app today, so this is a step your operator or an API client performs.
This is genuinely optional, and skipping it is not a downgrade in privacy. Without a personal key, summaries fall back to a plain structural description of the result, which reveals less than a written summary would. There is deliberately no borrowing of anyone else's key here: without your own, the private path is simply not used.
Troubleshooting
"Tool integrations are not enabled." The feature is off for your deployment. Nothing you can change.
"Tool integrations are not configured." The feature is on, but a required piece is not deployed yet. This is for your operator to resolve.
Browse is empty, or tool counts are missing. The catalogue is still warming after a restart. Wait a moment and reload; connecting does not depend on the counts.
A bot says it cannot use your tool. Most often your platform account is not linked to your account in the app yet, or the group has no rule granting access. Check Group access first.
A bot says the result is not shareable here. The tool ran, but your rule for that group is set to share nothing. That is the rule working as written.