Skip to content
ayx-rsv0.22.1

Alteryx One overview

ayx one is the primary command surface for Alteryx One. It gives you programmatic access to every major area of the platform: browsing and sharing cloud-native canvas workflows, managing data connections and datasets, running and inspecting jobs, orchestrating schedules and plans, and administering users and workspaces.

For authentication there are two first-class methods. Email OTP is the default interactive path and the quickest first run, but it is time-limited: its access token expires after 30 days and does not renew itself. OAuth2.0 API access/refresh credentials are the durable path — set up once, renewed silently from then on — and suit a person who would rather not re-authenticate monthly as much as they suit CI and agents. Both are workspace-scoped and documented in Identity & auth and Connecting.

Three workflow surfaces, deliberately kept separate

Section titled “Three workflow surfaces, deliberately kept separate”

This CLI reaches three different workflow-like surfaces. They are built on different underlying technologies, they do not share resources, and they are not interchangeable:

Surface Command prefix What it is
Cloud-native workflows ayx one workflows Alteryx One’s canvas surface, keyed by ULIDs. The execution unit in Alteryx One. See Workflows.
On-prem Designer/Server workflows ayx designer workflow Local .yxmd / .yxmc / .yxzp packages for Alteryx Designer and Server. The execution unit on-prem, and where the large majority of existing customer workflows still live. See Workflows & packages.

Because these are separate technologies rather than separate views of the same data, moving work between them is a migration, not a configuration change. Commands that cross the boundary say so explicitly — see ayx designer workflow migrate and the cloud-conversion notes in Workflows & packages.

Keep the distinction when reading the rest of these docs: a page under Alteryx One never describes on-prem Designer/Server behavior, and a page under Alteryx Server never describes cloud behavior.

All mutating commands are dry-run by default. Nothing changes on the server until you add --apply. Add --yes to skip the confirmation prompt in scripts. See the Safety model for the full rules.

Major areas

Section titled “Major areas”
Area Command prefix What you do
Workflows ayx one workflows List, inspect, run, cancel, copy, share, and delete cloud-native canvas workflows
Connections ayx one connections Manage data connections and connector metadata
Datasets ayx one datasets Browse the One dataset library and inspect dataset details
Jobs ayx one jobs Execute, cancel, inspect, and retrieve results for Job Library entries (ayx one job-groups remains a hidden compatibility alias)
Output objects ayx one output-objects CRUD for output objects; inspect inputs; convert to Python
Scheduling ayx one scheduling List schedules, enable and disable them
Plans ayx one plans Orchestrate multi-flow plans, manage schedules, share, import/export
Identity & users ayx one login / logout / whoami / auth / workspace / person / token / role Sign in/out, inspect identity, and administer workspaces, users, tokens, and roles
Write settings ayx one write-settings Configure where flows write their output data
Webhooks ayx one webhook-flow-tasks Create, inspect, delete, and test webhook-triggered flow tasks
Diagnostics ayx one doctor / ayx one inventory / ayx one api Health checks across auth, identity, plans, and scheduling; plus OpenAPI-spec and coverage introspection

How --apply keeps you safe

Section titled “How --apply keeps you safe”

Every command that modifies remote state prints a structured dry-run by default — it shows you exactly what request would be sent, then exits. Add --apply to commit.

Terminal window
# Shows what would be deleted; changes nothing
ayx one workflows delete <id>


# Actually deletes
ayx one workflows delete <id> --apply

For non-interactive automation (CI pipelines, scripts), add --yes to suppress the TTY confirmation prompt.

JSON output

Section titled “JSON output”

Pass -o json for machine-readable output on stdout. The historical --output json spelling remains supported, and the global flag can appear before or after the subcommand:

Terminal window
ayx one workflows list -o json

The envelope is { ok, message, timestamp_utc, data } on success; failures also include error_code. Combine with --verbose to get human-readable progress on stderr without polluting stdout.

Targeting a specific environment

Section titled “Targeting a specific environment”

Most commands accept --profile <name> to target a non-default workspace profile (each command’s page notes any exceptions).

Terminal window
ayx one workflows list --profile staging
Section titled “Related”