Integration accounts

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:

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:

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.

Get started

Concepts

Reference

Default account binding

Named bindings

Permissions

Static and dynamic selection

Credential safety

​Default account binding

​Named bindings

​Permissions

​Static and dynamic selection

​Credential safety

Default account binding

Named bindings

Permissions

Static and dynamic selection

Credential safety