Skip to content
Documentation
On this page

Connect an account

Save a credential once as an account, from the dashboard, the app you are configuring, or an agent, then select it for any app that needs that provider.

An account is one saved set of credentials for one provider. You connect it once. Every app that needs that provider can select it, and none of them holds a second copy.

There are two kinds of credential, and the provider decides which it accepts:

  • Secrets: fields you paste, such as an API token, or an email and a key.
  • OAuth: browser sign-in or a client ID and secret for machine-to-machine access. Executor stores and renews the resulting tokens.

From the hosted dashboard

Choose Connect new account at the end of a provider’s list on the app’s Accounts tab, then choose Connect to start browser sign-in. If the provider needs credentials, enter them in the same dialog. The connection dialog contains the sign-in methods supported by the provider.

The dialog uses the provider fields already loaded with the app. Opening it does not create a connection or fetch the fields again. A connection is created when you submit; retries in that dialog reuse the same request.

OAuth setup is checked in the background and reused across forms. If Executor can use a saved client or register one automatically, the dialog can connect without asking for client details. If your own client is required, its fields appear immediately. A failed check offers Retry without guessing which setup to show. Client IDs and secrets stay on the server during these checks.

The provider’s code declares the grant, endpoints, scopes, and authentication method. Open Advanced below Connect to review Required permissions. The dialog asks only for a client ID and, when required, a client secret. For browser sign-in, copy the fixed redirect URL into the OAuth app’s settings. Machine-to-machine connections complete in the dialog and need no browser redirect.

If saved OAuth client details are wrong, open Advanced below the Connect button, choose Change next to OAuth client, and enter the replacement. Executor saves manual client details only after a successful sign-in. A failed replacement keeps the previous client and account. If browser sign-in rejects the client, Update client details opens the form again.

You name an account after it connects. Executor names each new account Default, then Default 2, and so on when that name is already in use for the provider. Once the account is saved, or browser sign-in returns, a Name this account dialog offers to rename it to something such as “Work” or “Personal.” Closing it keeps the default. Reconnecting keeps the existing name. You can also rename an account later from its detail page.

Completing a connection saves the account and selects it for this app. There is no separate selection to save. Browser sign-in returns to the app’s Accounts tab; cancelling or failing sign-in offers a direct way back to the app.

The Accounts tab lists every compatible saved account under each provider. Choose one for a single-account requirement, or check the accounts to use for a multiple-account requirement. Each change is saved immediately. Connect new account at the end of the list adds an account and selects it. Members who can view an app but not use it see only the profile’s current accounts.

Removing an account from a single-account requirement, or unchecking it, changes only the profile’s selection. It keeps the saved account available to other apps. The global Accounts page lists saved accounts and the apps that use them.

From an agent

An agent can start the same flow. It must never ask you for a secret in chat, and must never read a token out of your files. It asks Executor for a connection link and gives you the link; you finish in your browser.

return await tools.executor.profiles["<management-profile-id>"].accounts.connect({
  path: { organization: "<organization-id>", app: "<app-id>" },
  body: { profile: "<profile-id>", requirement: "vercel" },
});
return await tools.executor.profiles["<management-profile-id>"].accountConnect.issue({
  body: { owner: "alice", target: { app: "<app-id>", profile: "<profile-id>", requirement: "vercel" } },
});

Create a profile first, or use the ID of your existing profile. Hosted uses profiles.create; local uses appProfiles.create. Read their discovered schemas for the required fields.

Supply either target, to fill a specific profile requirement, or provider, to save an account without selecting it anywhere. Not both.

Check whether you finished:

const connection = await tools.executor.profiles["<management-profile-id>"].accountConnections.get({
  path: { connection: "<connection-id>" },
});
return connection.state;

Completed means the account is saved. If the request named a target, the account is also selected for that requirement.

A pending request expires after thirty minutes. Issue a new one if it does.

How a targeted request fills a slot

  • A single-account requirement is replaced by the new account.
  • A .many() requirement appends the new account, and does not duplicate one that is already selected.
  • If the app’s requirement changed while the request was open, the request fails rather than filling the wrong slot.

Changing and removing an account

You can rename an account, replace its credentials, and remove it. Replacing credentials keeps the same account, so every app that selected it keeps working.

Removing an account does not silently unselect it. Apps that selected it keep the reference and report it as unavailable, and they cannot run until you choose a different account. That is deliberate: it makes a broken app visible instead of quietly changing which credentials an agent uses.

What is coming later

  • Per-person account selection. Today one app holds one selection for the whole organization, so a tool call uses the saved account rather than the caller’s own.

Was this page helpful?