White-labeling authentication

There are four places where Composio branding shows up during authentication:

Customizing the Connect Link

The Connect Link is the hosted page your users see when connecting their accounts. By default it shows Composio branding.

To replace it with your own branding:

1. Go to Project Settings → Auth Screen
2. Upload your Logo and set your App Title

This applies to all Connect Link flows across all toolkits, for both in-chat and manual authentication. Each project has one logo and app title, so if you need different branding per product, use separate projects.

Using your own OAuth apps

OAuth toolkits like Google and GitHub show a consent screen that says which app is requesting access. By default this reads "Composio wants to connect to your account." To show your app name instead, create a custom auth config with your own OAuth credentials and pass that auth config when creating a session.

Switching from Composio-managed to your own OAuth app

Existing connected accounts are tied to the auth config they were created with. Switching to a custom auth config affects new connections for that toolkit; existing users keep using their current connected accounts until they re-authenticate or you import/migrate their credentials.

• To use the custom config for new connections, pass authConfigs when creating or updating the session.
• Existing connections continue refreshing with their original auth config.
• To fully migrate an existing user, delete the old connected account and have them re-authenticate with the new auth config, or import their credentials into the new config where supported.

Routing the callback through your domain

During OAuth, the browser briefly redirects through backend.composio.dev so Composio can capture the auth token. Some toolkits also display this URL on the consent screen.

If you need to hide Composio's domain, you can proxy the redirect through your own domain instead.

Set the redirect URI to your domain

In your OAuth app's settings, set the authorized redirect URI to your own endpoint:

https://yourdomain.com/api/composio-redirect

Create a proxy endpoint

This endpoint receives the OAuth callback and immediately 302-redirects it to Composio:

PythonTypeScript

from fastapi import FastAPI, Request
from fastapi.responses import RedirectResponse

app = FastAPI()

@app.get("/api/composio-redirect")
def composio_redirect(request: Request):
    composio_url = "https://backend.composio.dev/api/v3.1/toolkits/auth/callback"
    return RedirectResponse(url=f"{composio_url}?{request.url.query}")

// pages/api/composio-redirect.ts (Next.js)
import type { NextApiRequest, NextApiResponse } from "next";

export default function handler(req: NextApiRequest, res: NextApiResponse) {
  const composioUrl = "https://backend.composio.dev/api/v3.1/toolkits/auth/callback";
  const params = new URLSearchParams(req.query as Record<string, string>);
  res.redirect(302, `${composioUrl}?${params.toString()}`);
}

Your endpoint must return a 302 redirect. Do not follow the redirect server-side or make a fetch call to Composio. The user's browser needs to be redirected so the OAuth flow completes correctly.

Update your auth config

In the Composio dashboard, update your auth config to use your custom redirect URI.

Here's how the redirect flow works. Your proxy just forwards the browser redirect to Composio. It never touches the authorization code or token.

Redirecting users after authentication

By default, after OAuth completes, users land on a Composio-hosted success page that shows Composio branding. To bypass this page and send users to your own domain instead, pass a callbackUrl when calling session.authorize():

connection_request = session.authorize(
    "gmail",
    callback_url="https://your-app.com/callback"
)

const connectionRequest = await session.authorize("gmail", {
  callbackUrl: "https://your-app.com/callback",
});

After authentication, Composio redirects the user to your callback URL instead of the default success page. For full details on the parameters appended to your callback URL, see Manually authenticating users → Redirecting users after authentication.

What to read next