Use multiple accounts from the same service

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:

automations/route-support-email.automation.ts

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:

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.

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

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.

Get started

Guides

Concepts

Reference

Use multiple accounts from the same service

Declare named bindings

Connect each account

Reuse bindings consistently

​Declare named bindings

​Connect each account

​Reuse bindings consistently

Declare named bindings

Connect each account

Reuse bindings consistently