Apex CLI

Authentication and context

Run apex login once to authenticate your account. Interactive login opens the browser and then lets you select an organization and shop. Inspect the credential and every accessible context with apex whoami, and switch the stored default with apex use <org>[/<shop>] (IDs and unambiguous name prefixes are accepted).

Every command also accepts --org <id> and --shop <id>. Their precedence is command flag, then DRIP_ORG / DRIP_SHOP, then the context saved by apex use. Falling back to the stored apex use context emits one warning on stderr so scripts can see the implicit selection without corrupting JSON stdout. Flags and environment variables are explicit choices and stay silent. JSON envelopes echo the effective org, shop, and credential kind.

Automation should continue injecting a narrow shop key per process with DRIP_API_KEY; it takes precedence over a stored user credential and does not change the stored login. Use apex login --api-key apx_uk_... for a headless account login or apex login --api-key apx_... to store a shop key. The old apex login --user spelling is a deprecated alias for apex login.

Command-line tools for Apex experiments, draft workspaces, GitOps pushes, QA evidence, tracking checks, and agent handoffs.

Install

npm install -g @drip-apex/apex-cli

Authenticate

apex login
apex whoami

apex login opens the default browser OAuth flow at Apex /cli/login. For headless environments, use an existing API key:

apex login --api-key apx_your_key_here
DRIP_API_KEY=apx_your_key_here apex experiments list --json

Common usage

apex experiments list
apex experiments list --include-archived
apex experiments create --name "Redirect test" --type redirect \
  --source-url "https://shop.example/products/source" \
  --destination "https://landing.example/products/treatment"
apex experiments pull <id-or-slug> --out ./my-test
apex experiments plan ./my-test --json
apex experiments apply ./my-test --json
apex experiments qa status ./my-test --json
apex experiments screenshots <id-or-slug> --out ./screenshots

apex workspace checkout <experimentId> --variation <variationId> --out ./workspace
apex workspace dev ./workspace --no-open
apex workspace publish ./workspace

apex push --dry-run
apex schema --json

Use apex as the canonical command name. drip is a compatibility alias.

apex experiments list hides archived experiments by default. Pass --include-archived to include them; archived rows display their archive date when the API provides archived_at.

Command index

Use apex schema --json to emit the complete machine-readable command surface, including every subcommand, argument, option, and alias.

Authentication and account

• apex login — authenticate with a shop or user API key.
• apex logout — remove stored credentials.
• apex whoami — inspect the current credential and its validity.
• apex account — manage the current user profile.
• apex keys — manage shop API keys.
• apex org — inspect and manage the organization.
• apex team — manage organization members and invitations.

Experiments and delivery

• apex experiments — create, inspect, operate, and synchronize experiments. Use apex experiments screenshots <id-or-slug> to force-assign every capture, including control, to its variation server-side for deterministic screenshots; choose devices with --devices, filter treatments with --variations, and use --json for the signed result payload.
• apex push — synchronize .drip.config.ts with Apex.
• apex preview — open a variation QA preview.
• apex roadmap — consume approved roadmap ideas and handoffs.
• apex harness — develop AB Test Harness projects with live QA sessions.
• apex workspace — check out, preview, and publish draft workspace files.
• apex goals — manage conversion and revenue goals.
• apex flags — manage feature flags.
• apex personalizations — manage personalization deliveries.
• apex backlog — manage experiment backlog items.
• apex signals — inspect research and opportunity signals.

Analytics, targeting, and tracking

• apex tracking — diagnose storefront tracking.
• apex environments — inspect delivery environments.
• apex analytics — read shop analytics.
• apex pages — manage page targeting resources.
• apex segments — manage audience segments.
• apex exclusion-groups — manage mutually exclusive experiment groups.
• apex targeting — inspect targeting evaluation and coverage.
• apex audit-log — inspect auditable account activity.
• apex inbox — use the operator inbox.

Shop configuration and operations

• apex external-pixels — manage external pixel snippets.
• apex assets — manage uploaded assets.
• apex landing-pages — discover landing pages.
• apex brand — manage brand context.
• apex sos — run operational diagnostics.
• apex shops — manage shops and active-shop context.
• apex skills — inspect agent skill guidance.
• apex admin — run authorized administrative operations.
• apex schema — emit the machine-readable CLI schema.

Which local format am I in?

Inspect the marker under .apex/: experiment-filesystem.json means the folder belongs to apex experiments pull/plan/apply, while session.json means it is an apex workspace checkout/status/publish workspace. Keep the two formats in different folders; when the wrong command is run, Apex points to the matching status command.

Push config format

Run apex push -c <config> to load a JavaScript or TypeScript config. The module's default export may be an experiment array, an object with an experiments array, or one experiment object. TypeScript (.ts or .tsx) is compiled and bundled on the fly with esbuild into a temporary ESM module; JavaScript (.js, .mjs, or .cjs) is imported directly.

Each experiment accepts these fields:

| Field | Format and mapping | | --- | --- | | slug | Required string and unique within the config; identifies the upsert. | | name | String sent as the experiment name. | | id | Optional string accepted in the config; it is not sent by push. | | trafficAllocation | Optional number sent as traffic_allocation; defaults to 1. | | targeting | Optional value sent as targeting; defaults to null. | | variations | Array of variation objects described below. | | goals | Optional array of { id: string }, mapped to goal_ids. | | description | Optional string; defaults to null. | | storeUrl / store_url | Optional string aliases sent as store_url; camelCase wins when both are present. |

Each variation accepts:

| Field | Format and mapping | | --- | --- | | id | Optional string, used as the fallback slug and name. | | slug | Optional string; falls back to id. | | name | Optional string; falls back to id, then "Unnamed". | | weight | Number sent as the variation weight. | | isControl / is_control | Optional boolean aliases; defaults to false. | | mutations | Optional array; defaults to []. | | css / custom_css | Optional string aliases sent as custom_css; defaults to null. | | js / custom_js | Optional string aliases sent as custom_js; defaults to null. | | resetJs / reset_js | Optional string aliases sent as reset_js; defaults to null. | | antiFlickerSelectors / anti_flicker_selectors | Optional string-array aliases; defaults to []. |

Push validates only that every experiment has a truthy slug, that slugs are not duplicated within the loaded config, and that the top-level export has one of the accepted shapes. It does not runtime-validate the other field types, required TypeScript fields (name, variations, or variation weight), nested goal/variation shapes, value ranges, or API-level constraints. The command upserts each experiment by slug with PUT /api/v1/experiments/by-slug/:slug; an existing slug is updated and a new slug is created.

Full documentation

Read the CLI reference on the docs site:

• https://docs.drip-apex.com/cli/install-auth
• https://docs.drip-apex.com/cli/commands-output

Maintainers: see the CLI release runbook.