> ## Documentation Index
> Fetch the complete documentation index at: https://docs.automate.ax/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Automate.ax automations are TypeScript programs.
> Use Bun for installation and command examples.
> Use Automate.ax for the product name and automate.ax for the package, CLI, and domain.
> Treat documented public APIs as current; do not invent transitional or deprecated names.

# Use multiple accounts from the same service

> Connect named account bindings and select the right identity for each trigger and action.

Named account bindings let one project use several accounts from the same integration service. For example, an automation can watch a support mailbox and send notifications from an operations mailbox without putting credentials in source code.

## Declare named bindings

Call the provider's account helper at module scope with a stable binding name, then pass each reference to the trigger or action that should use it:

```ts automations/route-support-email.automation.ts theme={null}
import { automation } from "automate.ax"
import {
  googleAccount,
  onGmailNewEmail,
  sendGmailEmail,
} from "automate.ax/gmail"

const supportGoogle = googleAccount("support")
const operationsGoogle = googleAccount("operations")

export default automation("Route support email", () => {
  const email = onGmailNewEmail({ account: supportGoogle })

  sendGmailEmail({
    account: operationsGoogle,
    subject: email.subject.transform(
      (subject) => `New support email: ${subject ?? "(no subject)"}`,
    ),
    text: "A new message arrived in the support mailbox.",
    to: "operations@example.com",
  })
})
```

The names `support` and `operations` identify project deployment bindings, not provider account IDs. The account helpers keep the service type attached to each reference, so a Google binding cannot accidentally be passed to an action that requires another service.

## Connect each account

Deploy the project:

```bash theme={null}
bunx automate.ax deploy
```

Automate.ax detects the permissions required for each service and binding. When a binding is not satisfied, the CLI asks you to select an eligible connected account, connect a new one, or reauthorize an account that needs broader permissions.

The provider credentials stay private. Only the binding names are present in automation code and deployment metadata.

## Reuse bindings consistently

Use the same binding name wherever work should use the same provider identity. For example, Gmail and Google Sheets share the Google service, so `googleAccount("operations")` identifies the same Google binding across both product subpaths.

Omitting `account` selects the `default` binding. You can also pass a binding string directly to a single-service action, but a typed account reference is clearer when several calls share one identity.

<Note>
  Trigger account selection must be static because Automate.ax configures event
  sources during deployment. Actions resolve their selected account when they
  execute.
</Note>

Changing which connected account satisfies a binding does not require changing every action. Select the replacement during a later deployment, and the successful deployment records the new choice.