v0.19.0

This release makes Alteryx One OAuth2.0 API access/refresh credentials a first-class authentication method for automation, agents, CI, and other unattended use. Email OTP remains the simplest default for an interactive human login.

Start here

For a normal human login:

ayx onboard

Answer y, enter the emailed 6-digit code and workspace password, then press Enter when asked to save the password securely. Confirm the connection with:

ayx one workspace current

For a computer, CI job, or agent, obtain an OAuth2.0 API access/refresh pair from the Alteryx One administration experience and import the refresh token without putting its value in command arguments:

ayx one login --auth-method oauth-refresh \
  --refresh-token-env AYX_ONE_API_REFRESH_TOKEN

The OAuth client ID and token endpoint are configured in the selected profile. Secure persistence stores the credential pair in the operating-system keyring; short-lived access tokens are refreshed automatically. The equivalent stdin form is --refresh-token-stdin, which is useful for secret managers and CI.

Authentication and security

• OAuth credential policy is stored per workspace, so switching workspaces does not borrow or overwrite another workspace’s credentials.
• Refreshed access tokens and provider-issued rotating refresh tokens are persisted when the credential is keyring-backed.
• Provider exchange and local keyring persistence cannot be one atomic transaction. If local persistence fails after the provider accepts the exchange, the CLI fails closed and instructs the operator to re-import a fresh provider-issued pair; it does not blindly retry the exchange.
• Environment and stdin imports avoid exposing token values in process arguments. Direct secret flags remain only as compatibility inputs and are discouraged in shared terminals and automation logs.
• A profile configured for auth_mode: service-principal cannot also declare a workspace user-credential policy. This prevents an unintended service principal fallback from bypassing the selected OAuth or OTP policy.
• Access-token-only imports remain a non-rotating compatibility path. They are not equivalent to an OAuth access/refresh pair.

Alteryx One token terminology

The OAuth2.0 access/refresh pair used by ayx one login is different from an API-token resource created or managed by ayx one token. The former authenticates the CLI and supports renewal; the latter is an Alteryx One resource lifecycle surface. They must not be substituted for each other without verifying the provider’s intended scope and grant.

Live validation and scope

The release-readiness validation covers current, non-recipe functionality:

• disposable BigQuery connection lifecycle and connector metadata/dry-run;
• temporary-group Viewer role assignment/removal, with the current assignment list 403 recorded as a provider scope limitation;
• ephemeral API token create/list/detail/delete lifecycle; and
• cloud-native /svc-workflow list/detail/dependencies/engines/tools plus run/cancel and reversible copy/delete coverage.

Legacy recipe/wrangledDataset execution, profiling, write settings, output object CRUD, and one job-groups run remain intentionally excluded. Cloud-native workflow execution is separate: one workflows run queues a Workflow Service run, and one workflows cancel targets the returned run/job id.

Upgrade and release integrity

The release workflow builds Linux, Windows, Intel macOS, and Apple Silicon macOS binaries when the v0.19.0 tag is pushed. It runs formatting, clippy, and the locked workspace test suite before packaging the artifacts. macOS signing and notarization remain conditional on the repository’s configured signing secrets.

See the getting started guide, authentication guide, and identity reference for cross-platform setup and recovery instructions.