White-label

Scenario: Acme's customers should see Acme everywhere — the OAuth consent screen, the tool names the model uses, the connect buttons. Protobox is Acme's infrastructure, not part of Acme's story.

Three layers make that true: whose OAuth app asks for consent, what the tools are called, and where the flow happens.

1. Your OAuth app asks for consent

By default, catalog connects use Protobox's managed OAuth apps — fastest to ship, but Google's consent screen names the managed app. Bringing your own OAuth client makes the consent screen say Acme:

await protobox.authConfigs.create('gmail', {
  mode: 'byo_oauth',
  credentials: {
    clientId: process.env.ACME_GOOGLE_CLIENT_ID!,
    clientSecret: process.env.ACME_GOOGLE_CLIENT_SECRET!,
  },
  scopes: ['https://www.googleapis.com/auth/gmail.send'],
});

Connects for that connector now run through your registration; tokens still land in Protobox's vault and never transit your process.

2. Speak your product's vocabulary

Models act better with names that match your domain — and your customers should never see a foreign tool id. Toolset overrides rename and re-describe tools at serve time:

// Key overrides by the tool's NAME — the identifier tools.listTools/search return.
await protobox.toolsets.update(toolset.id, {
  toolOverrides: {
    GMAIL_GMAIL_USERS_MESSAGES_SEND: {
      name: 'ACME_SENDREPLY',
      description: 'Send a reply to the customer from the connected support mailbox.',
    },
  },
});

Or from a terminal:

protobox toolsets override support GMAIL_GMAIL_USERS_MESSAGES_SEND --name ACME_SENDREPLY

Overrides are served live on every surface a toolset backs — sessions, published servers, adapters — with no separate publish step. The underlying tool is untouched; the override is your workspace's view of it.

3. The flow lives in your UI

Nothing in the connect path requires a Protobox-branded page in front of your users:

// Your backend, behind your own /integrations/connect endpoint:
const { authorizeUrl } = await protobox.entity(userId).connect('gmail');
// Your UI redirects to authorizeUrl (the provider's consent, showing YOUR app),
// then returns to YOUR redirect target when done.

Connection state, disconnect buttons, and your "app store" page all render from listConnections() and integrations.list() — your components, your styling. See Connect your users' apps.

What your customer experiences

1. Clicks Connect Gmail in Acme's settings.
2. Google consent screen: "Acme wants access to…".
3. Back in Acme. The assistant can now ACME_SENDREPLY.

No third-party name appears at any step.

Production notes

• BYO OAuth is per-connector. Prioritize the providers your customers see consent screens for most (usually Google/Microsoft); leave long-tail connectors on managed apps.
• Keep override names stable. Models and prompts key off tool names; renaming ACME_SENDREPLY mid-flight is a behavior change for every agent using the toolset.
• Scopes discipline: request the narrowest provider scopes your tools need — your name is on the consent screen now.

Related

• Managed auth reference
• Toolsets — the curation model behind overrides