Apollo.io CLI: Sales Intelligence Meets the Terminal

I’ve been on a kick lately building CLI tools that take useful-but-annoying APIs and make them actually pleasant to work with from the terminal. After gdelt-cli for global news data, the next target was obvious: Apollo.io.

If you’ve ever worked in sales, growth, or recruiting, you’ve probably used Apollo. It’s got one of the largest B2B contact databases out there — emails, phone numbers, company data, job postings, org charts. The web UI is fine for one-off lookups, but the moment you need to do anything at scale — enrich a list of 500 domains, bulk-update contact stages, pull sequence analytics — you’re either writing throwaway Python scripts against their API or clicking through pages until your eyes glaze over.

apollo-io-cli wraps the entire Apollo.io API into a single binary with 50+ operations. Rust, fast, JSON in and JSON out.

Two Ways to Talk to It

The design choice I’m most pleased with is the dual interface. There’s a traditional subcommand style that feels natural if you’re a human typing in a terminal:

# Search for people at a company
apollo contacts search --data '{"organization_name": "Stripe", "title": "engineer"}'

# Enrich a domain
apollo enrichment organization --domain "example.com"

# Check your API usage
apollo misc usage

And then there’s the exec mode — a flat, dot-notation interface designed for machines:

apollo exec contacts.search --data '{"organization_name": "Stripe"}'
apollo exec enrichment.organization --data '{"domain": "example.com"}'
apollo exec misc.usage

Same operations, same results. The exec style exists because when an AI agent is constructing commands, it’s much simpler to work with a single command (exec) plus an operation string than to navigate a tree of subcommands with different argument patterns. The agent just needs to know the operation name and the JSON payload.

Everything is JSON

This sounds obvious but it’s surprisingly rare in CLI tools. Every response — success or failure — is valid JSON:

{
  "success": true,
  "data": {
    "contacts": [...],
    "pagination": { "page": 1, "per_page": 25 }
  }
}

Errors too:

{
  "success": false,
  "error": {
    "code": "invalid_input",
    "message": "Operation 'contacts.get' requires --id parameter"
  }
}

No surprises. No random stderr messages that break your jq pipeline. Your automation can just check .success and branch accordingly.

Stdin Streaming

This is where it starts to compose nicely with other tools. You can pipe JSON into any operation:

# Bulk create contacts from a file
cat contacts.json | apollo exec contacts.bulk-create

# Enrich a single email from a pipeline
echo '{"email": "[email protected]"}' | apollo enrichment people

# Chain with jq for transformations
apollo contacts search --data '{"title": "CTO"}' \
  | jq '.data.contacts[].email' \
  | xargs -I {} apollo enrichment people --data '{"email": "{}"}'

Standard Unix philosophy. Small, composable pieces. The CLI reads from stdin when there’s no --data flag, so it slots into pipelines naturally.

The Full Operation Map

50+ operations across the entire Apollo API surface:

Enrichment — the thing most people want first. Look up people by email, enrich organizations by domain, with both single and bulk variants.

Search — find people, organizations, job postings, and news. There’s a credit-free people search endpoint (search.people-api) if you’ve got a master API key.

Contacts & Accounts — full CRUD plus bulk operations. Create, get, update, search, bulk-create, bulk-update, bulk-owner-update, stage management.

Deals — create, list, get, update opportunities. Pull deal stages.

Sequences — search sequences, add contacts to them, activate, check email stats. This is the big one for outbound automation.

Tasks & Calls — create and manage tasks, log call records, search phone interactions.

Utilities — health checks (validate your API key works), usage stats (quota and rate limits), user management, email accounts, custom fields.

Setting It Up

You need an Apollo.io API key. Grab it from Settings > Integrations > API in your Apollo dashboard, then:

export APOLLO_API_KEY="your_key_here"

Install the binary:

# Via npm (easiest)
npm install -g apollo-io-cli

# Via cargo
cargo install --git https://github.com/dipankar/apollo-io-cli

# From source
git clone https://github.com/dipankar/apollo-io-cli
cd apollo-io-cli
cargo build --release

There are also man pages if you’re into that:

cargo run --example gen_manpages
./install-man.sh
man apollo

Why Rust, Why a CLI

The same reasons as gdelt-cli. Rust gives you a single static binary with no runtime dependencies — no Python version conflicts, no node_modules, no virtualenvs. It starts instantly. It handles concurrent requests efficiently through Tokio. And the type system catches a whole class of serialization bugs at compile time that would be runtime errors in a dynamic language.

The CLI form factor matters because it’s the universal integration point. Shell scripts, cron jobs, CI pipelines, AI agents — everything can call a CLI. You don’t need to import a library or match a language runtime. Just call the binary and parse the JSON.

The Agent-First Angle

This is part of a broader pattern I’m exploring: building CLI tools that are natively consumable by AI agents. Not as an afterthought — “oh we should add a JSON mode” — but as a primary design constraint from day one.

The characteristics that make a CLI agent-friendly:

1. Flat operation namespace — the exec mode with dot notation
2. JSON everywhere — inputs, outputs, errors, all machine-parseable
3. Stdin streaming — agents can construct payloads and pipe them in
4. Structured errors — error codes your agent can switch on, not prose it has to interpret
5. Self-describing — built-in help and examples the agent can query

Combined with MCP integration (like in gdelt-cli), you get tools that AI assistants can wield as naturally as they use a calculator. The agent doesn’t need to screen-scrape a web UI or reverse-engineer an undocumented API — it just calls the CLI with the right operation and payload.

The project is MIT licensed and on GitHub. If you’re doing anything with Apollo.io at scale, or building AI workflows that need access to sales intelligence data, give it a spin.