> ## 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.

# Integration accounts

> Authorize external services and select account bindings without exposing credentials.

An integration account gives actions and triggers access to an external
service. Automate.ax manages OAuth tokens and API credentials; automation code
selects a logical account binding, never the secret itself.

## Default account binding

Account-backed actions and triggers use the service's `default` binding when
`account` is omitted:

```ts theme={null}
const email = onNewEmail()

sendEmail({
  to: "person@example.com",
  subject: "Hello",
  text: "Sent with the default Google account binding.",
})
```

During deployment, the CLI asks you to connect or select an eligible Google
account when the binding has not been satisfied.

## Named bindings

Use a stable name when one project needs several accounts for the same service:

```ts theme={null}
const email = onNewEmail({ account: "support" })

sendEmail({
  account: "billing",
  to: email.replyTo.transform(
    (recipients) => recipients[0]?.address ?? "fallback@example.com",
  ),
  subject: "Billing follow-up",
  text: "We received your request.",
})
```

The strings `support` and `billing` identify project deployment bindings. The
CLI assigns an authorized Google account to each one.

## Permissions

Every account-backed action and trigger declares the provider permissions it
requires. Deployment combines requirements for each service and binding, then
checks whether the selected account satisfies them. If authorization is
missing, deployment pauses and guides you through connecting or reauthorizing
an account before publishing.

Adding an operation that needs broader permissions can therefore require
reauthorization on the next deployment.

## Static and dynamic selection

* Trigger account selection must be static because Automate.ax configures event
  sources during deployment.
* A single-service action can select a literal binding, typed account reference,
  or compatible signal because its account is resolved during execution.
* An action that accepts multiple services requires a typed account reference so
  Automate.ax knows which provider to authorize during deployment.

An account reference for the wrong service is rejected. For example, a Slack
account reference cannot satisfy a Gmail action.

## Credential safety

Provider credentials do not enter automation inputs, signal values, deployment
manifests, or source code. The runtime resolves the selected binding privately,
refreshes credentials when necessary, and exposes them only to the integration
action implementation.

Account choices are recorded with each successful deployment. A later
deployment can select a different account without rewriting every action that
uses the same logical binding.