White-labeling (direct execution)
The White-labeling authentication guide covers both hosted Connect Link branding and app-owned connection UI. The same OAuth app and callback rules apply whether you use direct tool execution or sessions.
Customizing the Connect Link
Use composio.connectedAccounts.link(userId, authConfigId, { callbackUrl }) in TypeScript or composio.connected_accounts.link(user_id=..., auth_config_id=..., callback_url=...) in Python to start a hosted flow without a session. The server-side cURL example shows the equivalent API request.
Set your project's logo, app title, theme, and language as described in Customizing the Connect Link. Branding changes the hosted page, not its connect.composio.dev domain or the provider's consent screen.
Using your own OAuth apps
Create a custom auth config with your provider's client credentials to show your app identity on the consent screen. Pass that config's ID when starting the connection. The provider's registered redirect URI must exactly match oauth_redirect_uri in the auth config.
When to use your own OAuth apps
Use custom credentials when your product needs its own consent-screen identity, scopes, or quotas, or when you need the supported direct-initiation path for an app-owned UI. API-key toolkits don't have an OAuth consent screen.
Switching from Composio-managed to your own OAuth app
Existing connected accounts remain tied to their original auth config. New connections can use the custom config; a branding change doesn't migrate existing accounts. See Switching auth configs.
Sending users directly to the OAuth provider
For supported custom OAuth2 configs, connectedAccounts.initiate() accepts config.val.long_redirect_url: true to request an unshortened authorization URL. Your app can render the connect button, required fields, progress, and result screens instead of using Connect Link. Follow Build an app-owned connection UI for cURL and SDK examples.
long_redirect_url controls URL shortening. It doesn't remove Composio's return callback or guarantee that every toolkit skips every intermediate page. Inspect the actual URL chain for each toolkit. The Composio-managed OAuth path of initiate() has been retired; use link() for managed OAuth. See Migrating from initiate to link.
Routing the callback through your domain
A custom provider callback endpoint can forward the browser to Composio with a 302 response where the toolkit supports it. This does not hide backend.composio.dev: the browser still visits Composio after your endpoint. Your endpoint receives the authorization code and state, so its query string must not be captured in application, CDN, analytics, or error logs.
See Callback domains and forwarding for the supported response shape and the difference between the provider's redirect_uri and your application's callbackUrl. Use the latter to return to your own result page after authentication, not to replace the provider callback.
Verify before enabling access
Save each connection attempt against the authenticated application user on your server. Don't trust callback query parameters alone. Verify the saved account ID, user binding, auth config, toolkit, and active status before using it for direct tool execution. Apply any provider-identity policy separately, and complete the deployment checklist.
Next
Connected accounts
Manage and monitor user connections to toolkits