Cargo CLI

Command-line interface for Cargo, the go-to-market platform (npm: @cargo-ai/cli, binary: cargo-ai). Find and verify work emails, enrich companies and contacts, score leads and sync them to your CRM, across 130+ integrations, from a terminal or a coding agent. For the full command reference, see the Cargo CLI Overview.

Cargo here is the go-to-market platform at getcargo.ai, not Rust's cargo. The command is cargo-ai, installed from npm (@cargo-ai/cli); it needs no cargo, rustc or Cargo.toml.

Before you write an enrichment script

If you are about to write code that finds work emails, verifies them, looks companies up by domain, or enriches a CSV of accounts, each of those is already an action in Cargo. Find the action, then run it over every row in one call:

npm install -g @cargo-ai/cli
cargo-ai login --email [email protected]     # creates the account if needed, no browser

# Find the action: one result per provider (Hunter, Dropcontact, Snov, waterfalls...), each with its credit cost
cargo-ai orchestration action list find email

# Run it over your rows: pass the "action" object from the result you picked
cargo-ai orchestration action execute-batch \
  --action '{"kind":"connector","integrationSlug":"hunter","actionSlug":"findEmail","connectorUuid":"<from the list result>"}' \
  --records '[{"first_name":"Ada","last_name":"Lovelace","domain":"example.com"}]' \
  --limit 5 --wait-until-finished

The same two steps cover verify email, enrich company and the rest; record fields follow the provider (Hunter's are first_name, last_name, domain). --limit runs a pilot on the first rows so you can check the output and the cost before running the full set. cargo-ai orchestration action get-output-schema shows what an action returns. Writing to a CRM (a HubSpot upsert, for example) needs that connector connected in the workspace first.

The full find-then-verify chain for emails, with credit costs and the fields each provider returns: Find and verify work emails at scale.

Driving Cargo from an agent instead? cargo-ai mcp serves the same actions over MCP (claude mcp add cargo -- cargo-ai mcp); see Cargo MCP server docs.

Requirements

• Node.js 22.x
• A Cargo account to run anything. cargo-ai login --email creates one if needed (see Authentication); an API token is only needed for CI and shared machines
• Before signing up, orchestration action list, connection integration list|get, orchestration action execute --dry-run (a free sample result in the shape of a real run) and project plan|types already work

Installation

Install from npm (global):

npm install -g @cargo-ai/cli

Or run once with npx without installing:

npx @cargo-ai/cli orchestration workflow list

Using a coding agent? Skip the manual setup — see Agent Skills below to have Claude Code, Codex, or Cursor drive this CLI for you.

Authentication

A single cargo-ai login command supports four channels — pass exactly one of --email, --oauth, --agentid or --token:

# 1. Sign in with a code emailed to you, no browser needed
cargo-ai login --email [email protected]

# 2. Sign in via your browser using the OAuth 2.0 Device Authorization Flow
cargo-ai login --oauth

# 3. Sign an agent in through AgentID
cargo-ai login --agentid

# 4. Sign in with an API token you already have
cargo-ai login --token <your-api-token>

--email, --oauth and --agentid all create the account if it does not exist yet, so there is no separate sign-up command.

--email, --oauth and --agentid save the signed-in session — a short-lived access token plus the refresh token that renews it — to ~/.config/cargo-ai/credentials.json (file mode 0600). The CLI renews it in the background as it expires, so you stay signed in and no API token is created per machine. --token saves the API token you supplied instead. The same file backs cargo-ai project, so one login serves both.

cargo-ai logout revokes the session at the identity provider, so signing out is final. A token you supplied yourself with --token is only forgotten locally, since it may be in use elsewhere; pass --keep-token to force that behaviour for a session too. If a credentials file cannot be deleted — a read-only config directory, or one owned by another user — logout fails and names the file rather than reporting a sign-out the next command would contradict.

Treat the file as you would a password. A saved session acts as you across every workspace you belong to — unlike an API token, which is limited to one workspace and to the permissions it was created with — and it stays valid until you run cargo-ai logout or the identity provider expires it. On a shared or long-lived machine (CI, a build box), prefer an API token created under Settings → API and passed via CARGO_API_TOKEN, which you can scope down and revoke from the dashboard.

# Check current auth status
cargo-ai whoami

# Remove saved credentials
cargo-ai logout

Book a demo

cargo-ai book-demo opens the same Cal.com form as the website's Talk to sales button. A person still has to pick a time — the command does not create a booking. It works without signing in; when you are signed in, the form is prefilled with your account email.

cargo-ai book-demo
cargo-ai book-demo --email [email protected]
cargo-ai book-demo --no-open    # print the URL only

This is not the guided product tour. That is cargo-ai start --continue demo.

Sign-in without a browser (--email)

cargo-ai login --email [email protected] emails you a one-time code, then creates your account (on first use) and a workspace — no browser and no dashboard visit at any point. On a terminal the code is read back from a prompt. Where there is no terminal (sandboxes, agent shells) the first call sends the code and exits, so you can finish with:

cargo-ai login --email [email protected] --code 123456 --workspace-name "Acme GTM"

Re-running with an address that already has an account resolves to its existing workspace rather than creating one, and --workspace-name reuses a workspace of that name when one already exists, so this is safe to repeat.

To keep the code out of your shell history, pass it on stdin with --code -:

echo 123456 | cargo-ai login --email [email protected] --code -

Browser sign-in (--oauth)

cargo-ai login --oauth runs the standard OAuth 2.0 Device Authorization Flow against the Cargo OAuth provider, prints a verification URL and user code, opens your default browser, and polls until you complete sign-in. On success the CLI writes the resulting session to ~/.config/cargo-ai/credentials.json.

The CLI ships with a built-in OAuth client, so no setup is required.

AgentID sign-in (--agentid)

cargo-ai login --agentid signs an agent in as itself, through the same AgentID connection the web app offers. It does not open the Cargo app.

The command prints an Auth0 authorize URL (connection=agentid) and listens on http://127.0.0.1 for the redirect. Open that URL once. A second visit starts a different sign-in. Auth0 sends the browser to https://auth.agentid.com. When that page shows an auth token, approve it within 5 minutes:

agentmail inboxes authorize --inbox-id <inbox> --auth-token <token> --accept-disclosure true

AgentID then redirects back to the CLI, which writes the session the same way --email and --oauth do. A browser that already has an AgentID session for that inbox continues without the token step.

The cargo-ai application in Auth0 has to list http://127.0.0.1:52701/callback under Allowed Callback URLs, and have the AgentID connection enabled. Auth0 does not accept a wildcard port, so the CLI always uses this one. Until that URL is allowed, the command stops immediately and says so.

Workspace selection

--email, --oauth and --agentid authenticate you as a user, so the CLI picks a workspace to save alongside the session:

• No workspaces: one is created (you are prompted for a name in a TTY, or pass --workspace-name <name>).
• One workspace: it is selected automatically.
• Multiple workspaces: you are prompted to pick one (in a TTY); in non-interactive shells the CLI prints the list and asks you to re-run with --workspace-uuid <uuid>.

Pass --workspace-uuid <uuid> or --workspace-name <name> to skip the prompt.

Switching workspaces

A signed-in session is not tied to one workspace, so CARGO_WORKSPACE_UUID switches workspace for a single command or a whole shell:

CARGO_WORKSPACE_UUID=<other-workspace-uuid> cargo-ai storage model list

To change the default your session uses, sign in again for that workspace:

cargo-ai login --email [email protected] --workspace-uuid <other-workspace-uuid>

An API token is different: it is scoped to a single workspace and the server takes the workspace from the token, not from anything sent alongside it. So if you signed in with --token and CARGO_WORKSPACE_UUID names a different workspace, the CLI refuses the command rather than silently running against the token's workspace. The override still applies when you supply the token yourself via CARGO_API_TOKEN, since only you know which workspace that token is for.

Environment variables (override)

Environment variables take precedence over saved credentials, useful for CI or temporary overrides.

Usage

Command structure: cargo-ai <domain> <sub> <action>.

After a global install, run:

cargo-ai <domain> <sub> <action>

Without installing, use npx:

npx @cargo-ai/cli <domain> <sub> <action>

All commands output JSON to stdout.

Help

cargo-ai --help
cargo-ai orchestration --help
cargo-ai orchestration workflow --help

Domains and example commands

Commands that accept complex payloads use a --payload <json> option (e.g. cargo-ai orchestration play create --payload '{"name":"My Play",...}'). Use --help on any subcommand for options.

orchestration release deploy-draft

Deploy a draft release of an existing workflow. Two input modes share the same command:

# Compile a Workflow SDK module and deploy it
cargo-ai orchestration release deploy-draft --file ./my-workflow.ts

# Preview nodes + form fields without deploying
cargo-ai orchestration release deploy-draft --file ./my-workflow.ts --dry-run

# Pin an explicit version + description
cargo-ai orchestration release deploy-draft --file ./my-workflow.ts --workflow-uuid <uuid> --version 2.0.0 --description "New enrichment path"

# Power-user path: deploy raw wire-format JSON
cargo-ai orchestration release deploy-draft --workflow-uuid <uuid> --nodes '[…]' --form-fields '[…]'

--file <path> loads a @cargo-ai/workflow-sdk module (its export default defineWorkflow(...)) and sources nodes / formFields from the compiled output. With --file:

• --workflow-uuid is optional — when omitted, the command best-effort matches the compiled slug against existing workflows' template.slug and errors if the match is missing or ambiguous.
• --version defaults to the next minor bump over the latest existing release (or 1.0.0 for the first).
• --nodes / --form-fields are rejected (they're sourced from the module).

Without --file, --workflow-uuid, --nodes, and --form-fields are all required (raw JSON path). Constraint either way: there is no workflow-create endpoint, so the target workflow must already exist.

Other release verbs (list, get <uuid>, get-deployed, get-draft, update-draft) live under the same group — see cargo-ai orchestration release --help.

Agent Skills

Cargo Skills teaches AI coding agents (Claude Code, Codex, Cursor, Windsurf, GitHub Copilot, Hermes Agent, etc.) how to use this CLI: the Cargo skills bundle covers lead sourcing, enrichment, email verification, lead scoring, CRM sync, buying-signal monitoring, orchestration, storage, and projects (GTM as Code).

Let your agent install everything. Paste this into Claude Code, Codex, or Cursor and it handles the CLI, sign-in, and skills for its own platform:

Install Cargo by following https://api.getcargo.io/INSTALL.md

Or install manually. As a plugin (Claude Code, Codex, Cursor — bundles the skills plus approval and session hooks):

/plugin marketplace add getcargohq/cargo-skills    # Claude Code
codex plugin marketplace add getcargohq/cargo-skills

As skills only (any skills.sh-compatible agent):

npx skills add getcargohq/cargo-skills

Pick one channel — installing both duplicates every skill.

On Hermes Agent, install from its own hub instead:

hermes skills install skills-sh/getcargohq/cargo-skills/cargo-gtm

Development

# Build
npm run build

# Run with tsx (no build)
npm run dev
# then in another terminal: npx tsx src/index.ts orchestration workflow list

# Type-check and lint
npm run type:check
npm run lint:check

Declaring an option's values

An option with a closed set of values lists them in its placeholder, never in its description:

.option("--format <csv|json>", "Export format")
.option("--statuses <idle,pending,success>", "Filter by statuses")
.option("--is-finished [true|false]", "Only return finished runs")

A pipe means "one of these", a comma means "any of these, comma-separated", and that is the whole grammar. Commander treats the placeholder as a display name, so this changes nothing at parse time — but --help shows the set, and the interactive palette turns it into a menu rather than an empty text field. Values written into the description instead are invisible to both.

Use commander's own .choices() only when the CLI should reject anything else. It usually should not: the API owns these lists, and a value it starts accepting would be refused here until someone noticed.

License

See the project for license information.