Migrate from Composio
Move an existing Composio integration to Open Connector without moving credentials through agent code.
Open Connector provides a Composio-compatible API mount for the connection and tool workflow. A migration is not a database import: create equivalent auth configs and connections in Open Connector, then change the client base URL after the new path is verified.
Migration plan
- Inventory your current use. List the toolkits, auth modes, connected-account identifiers, and trigger or webhook routes your product calls.
- Choose the target. Use Open Connector Cloud or deploy a self-hosted instance. The repository's current production runbook is Deploy to AWS.
- Create project-scoped API keys. One project key scopes connections and tool calls to the target project.
- Recreate auth configs. Select the connector and either use an available managed OAuth configuration or provide your own OAuth client credentials.
- Reconnect users. OAuth tokens are credentials—not portable application data. Send each user through a new hosted connect link or initiate the connection from your application.
- Run a canary. Point one environment or a small tenant set at Open Connector, verify the exact tools you use, then switch the remaining traffic.
Change the client endpoint
Choose the native SDK for new code, or change the Composio constructor's base URL for the smallest migration diff:
import { createClient } from "@open-connector/sdk";
const oc = createClient({
apiKey: process.env.OPEN_CONNECTOR_API_KEY!,
baseUrl: "https://api.openconnector.dev",
});import Composio from "@composio/client";
const composio = new Composio({
apiKey: process.env.OPEN_CONNECTOR_API_KEY!,
baseURL: "https://api.openconnector.dev/composio",
});For a self-hosted instance, replace the origin only:
https://connector.example.com/composioFor the native SDK, use the origin without /composio. Do not append /api/v3.1 to the Composio baseURL; that client appends the versioned path itself.
Recreate OAuth configuration
When you use your own GitHub OAuth app, add this callback URL in GitHub before testing:
https://api.openconnector.dev/api/v1/connectors/github/callbackFor self-hosting, replace the origin with your public broker origin. Create the auth config in Auth Configs and connect an account in the console, or use the compatible API from your trusted backend. Existing Composio access tokens should not be copied into a new OAuth connection; re-authorize the account through the provider.
Validate before cutover
Use a project key and the same connection identifier to check the account, discover tools, and execute a harmless request:
curl "https://api.openconnector.dev/composio/api/v3.1/connected_accounts/conn_..." \
-H "x-api-key: $OPEN_CONNECTOR_API_KEY"
curl "https://api.openconnector.dev/composio/api/v3.1/tools?toolkit_slug=github" \
-H "x-api-key: $OPEN_CONNECTOR_API_KEY"Then execute the exact tool and input shape your production workflow uses. Check the connection status and the API response; do not treat catalog presence as proof that a provider credential or optional subsystem is ready.
Endpoint mapping
| Composio path | Open Connector hosted path |
|---|---|
https://backend.composio.dev/api/v3.1/auth_configs | https://api.openconnector.dev/composio/api/v3.1/auth_configs |
https://backend.composio.dev/api/v3.1/connected_accounts | https://api.openconnector.dev/composio/api/v3.1/connected_accounts |
https://backend.composio.dev/api/v3.1/tools/execute/{slug} | https://api.openconnector.dev/composio/api/v3.1/tools/execute/{slug} |
https://backend.composio.dev/api/v3.1/toolkits | https://api.openconnector.dev/composio/api/v3.1/toolkits |
Verify optional capabilities separately
The compatible surface contains more than the core connect-and-execute loop, but optional subsystems depend on host configuration. If you use webhooks, triggers, files, tool-router, or MCP routes, test the exact route and deployment configuration before migrating that workload. An explicit 501 Not Implemented means the deployment has not bound that subsystem.