48cdd3a2a9
## Summary
- Clarifies in the root README that managed integrations are backend-proxied through OpenHuman's Composio connector layer.
- Updates the integrations docs to distinguish managed mode from direct Composio mode.
- Documents that direct mode needs the user's own Composio API key and separately hosted trigger webhook plumbing.
## Problem
- #2020 asks for clearer disclosure around cloud/backend and integration dependencies.
- The README advertised 118+ integrations with one-click OAuth, but did not state the managed Composio/backend boundary near that claim.
- The integrations page said users did not need to think about Composio, which is true for managed mode but incomplete for direct/BYO mode.
## Solution
- Add a short managed-vs-direct disclosure beside the README integrations bullet.
- Replace the vague Composio parenthetical in the integrations docs with explicit backend, OAuth, rate-limit, and webhook responsibilities.
- Add the direct-mode privacy-boundary change near the existing Privacy boundary section.
## Submission Checklist
- [x] Tests added or updated (happy path + at least one failure / edge case) per [Testing Strategy](../gitbooks/developing/testing-strategy.md#failure-path-requirement) — N/A: docs-only clarification.
- [x] **Diff coverage ≥ 80%** — N/A: docs-only change.
- [x] Coverage matrix updated — N/A: docs-only change.
- [x] All affected feature IDs from the matrix are listed in the PR description under `## Related`
- [x] No new external network dependencies introduced (mock backend used per [Testing Strategy](../gitbooks/developing/testing-strategy.md#mock-policy))
- [x] Manual smoke checklist updated if this touches release-cut surfaces — N/A: docs-only change.
- [x] Linked issue closed via `Closes #NNN` in the `## Related` section — N/A: #2020 is broader; this PR references it as a scoped docs follow-up.
## Impact
- Users evaluating OAuth/integration architecture get clearer docs before connecting accounts.
- No runtime behavior changes.
## Related
- Refs: #2020
- Follow-up PR(s)/TODOs: N/A
- Coverage matrix feature IDs: N/A: docs-only change.
---
## AI Authored PR Metadata (required for Codex/Linear PRs)
### Linear Issue
- Key: N/A
- URL: N/A
### Commit & Branch
- Branch: codex/2020-composio-disclosure-docs
- Commit SHA: 0d5a7ec2
### Validation Run
- [x] `pnpm --filter openhuman-app format:check` — N/A: docs-only change.
- [x] `pnpm typecheck` — N/A: docs-only change.
- [x] Focused tests: N/A: docs-only change.
- [x] Rust fmt/check (if changed): N/A: no Rust files changed.
- [x] Tauri fmt/check (if changed): N/A: no Tauri files changed.
- [x] `git diff --check`
### Validation Blocked
- `command:` N/A
- `error:` N/A
- `impact:` N/A
### Behavior Changes
- Intended behavior change: documentation now names the managed Composio/backend path and direct-mode responsibility split.
- User-visible effect: clearer README/GitBook disclosure for integration setup.
### Parity Contract
- Legacy behavior preserved: no code paths changed.
- Guard/fallback/dispatch parity checks: N/A.
### Duplicate / Superseded PR Handling
- Duplicate PR(s): N/A
- Canonical PR: N/A
- Resolution (closed/superseded/updated): N/A
<!-- This is an auto-generated comment: release notes by coderabbit.ai -->
## Summary by CodeRabbit
* **Documentation**
* Clarified how Composio-backed integrations work in managed mode versus the new direct mode
* Updated documentation to explain that managed mode handles OAuth, rate limits, and webhooks through the backend, while direct mode requires users to manage webhooks with their own Composio API key
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/tinyhumansai/openhuman/pull/2325?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: aqilaziz <gonzes7@gmail.com>
Co-authored-by: Steven Enamakel <enamakel@tinyhumans.ai>
description, icon
| description | icon |
|---|---|
| 118+ third-party integrations - Gmail, Notion, GitHub, Slack, Stripe, Calendar and more - with one-click OAuth and zero API keys. | plug |
Third-party Integrations (118+)
OpenHuman ships with backend-proxied access to 118+ third-party services. Connecting any of them through the managed path is a one-click OAuth flow inside the app, there are no API keys to wire by hand, and no plugin marketplace to navigate.
Under the hood, the connector layer is powered by Composio. In the default managed mode, OpenHuman's backend owns the Composio API key, OAuth token brokering, rate limits, and trigger webhook fan-out. If you switch to direct mode, the core talks to Composio with your own Composio API key; synchronous tool calls work, but real-time trigger webhooks must be configured on your own webhook infrastructure.
Once a service is connected, it shows up in four places at once:
- As an agent tool, the model can call it directly.
- As a memory source, auto-fetch syncs it into the Memory Tree every twenty minutes.
- As a profile signal, your activity across services feeds your personalization.
- As a trigger source, live events (a new email, a new charge, an inbound DM) flow into the Triggers pipeline and can fire off agent actions automatically.
Some of what's in the catalog
The catalog spans productivity, business, social, messaging and Google. A non-exhaustive sample:
| Category | Examples |
|---|---|
| Email & calendar | Gmail, Outlook, Google Calendar, Apple Calendar |
| Docs & storage | Google Docs, Google Drive, Notion, Dropbox, Airtable |
| Code & dev | GitHub, Linear, Jira, Figma |
| Comms | Slack, Discord, Microsoft Teams, Telegram, WhatsApp |
| CRM & sales | Salesforce, HubSpot |
| Commerce & payments | Stripe, Shopify |
| Project management | Asana, Trello |
| Social | Twitter / X, Spotify, YouTube |
Native vs proxied
Some services have native providers. Rust modules that know how to ingest the service into the Memory Tree directly (e.g. Gmail's native ingest path). Others are exposed as proxied tools only: the agent can call them, but there's no automatic ingest yet. New native providers are added as features land.
How connections work
Click Connect on any integration. A browser window opens for OAuth. Once you sign in, the connection becomes active and OpenHuman starts syncing it through auto-fetch on the next 20-minute tick.
Each integration shows its current status:
- Not connected. integration has not been set up.
- Connected. integration is active and being synced.
- Manage. active integration with options to reconfigure or disconnect.
You can revoke any connection at any time from the Skills tab.
Messaging channels
Three integrations are special. OpenHuman uses them to talk back to you, not just read from them:
- Telegram. the primary messaging channel. Two-way: send and receive messages, manage chats, search history, create groups, 80+ actions on your behalf. All actions run through your own encrypted credentials.
- Discord. send and receive messages via Discord. Connect your account to receive OpenHuman messages there.
- Web. a browser-based chat interface within the desktop app. Messages stay entirely local.
Set your default under Settings → Automation & Channels → Messaging Channels. The active route status shows which channel is currently in use. Telegram offers two credential modes: connect via OpenHuman (one-click, encrypted) or provide your own credentials for maximum control.
Skills
Beyond third-party services, OpenHuman has skills, small sandboxed modules that run inside the app, fetch external data, run on a schedule, transform information, and respond to events. Each runs with enforced resource limits. Skills install from the Skills tab and integrate with the same Memory Tree as everything else.
Native voice and tools
Two capabilities ship native rather than as integrations because they're load-bearing for the desktop experience:
- Voice. STT in, TTS out, plus a live Google Meet agent that joins meetings, transcribes them into your Memory Tree, and can speak back into the call.
- Native tools. built-in web search, web-fetch scraper, and a full filesystem/git/lint/test/grep coder toolset that the agent uses out of the box.
Privacy boundary
OpenHuman's core never calls any third-party API directly. All requests go through the OpenHuman backend, which handles OAuth tokens and rate limiting. Your tokens never sit on disk in plaintext on your machine, and the agent only sees the results of tool calls, not the credentials.
If you opt into direct Composio mode, that boundary changes: your local core uses your own Composio API key and you are responsible for the Composio account, rate limits, billing relationship, and any webhook endpoint needed for trigger delivery.
See Privacy & Security for the full boundary.
See also
- Triggers, live events from connected integrations and how they fire agent actions.
- Auto-fetch from Integrations
- Memory Tree