The reply CLI is built to be driven by coding agents, shell scripts, and CI. It handles the parts
that are tedious to reimplement — browser login, token refresh, the team header, retries — and
exposes the whole v3 API through
reply api. That command is the agent surface today; there are no
dedicated resource commands yet.
The --json contract
Every command accepts --json (compact) and --pretty (indented). Data goes to stdout, status
and errors go to stderr — pipes stay clean:
reply api always emits JSON, with or without a flag — {"code": <http status>, "data": <body>}.
--pretty only changes the indentation.
Exit codes
The two error shapes
reply api never hides an HTTP response. Any status, including 4xx and 5xx, is printed on
stdout as {code, data}, where data is the v3 problem+json body verbatim. The exit code is 1
for >= 400. Branch on .code:
Every other command reports failures as a single machine-readable line on stderr when
--json or --pretty is set:
Branch on code, surface hint to the user. Every field except title is optional.
Retries and rate limits
Handled inside the CLI, on both paths:
429, 500, 502, 503, and 504 are retried up to 3 times.Retry-After is honored when present, capped at 30 seconds; otherwise the backoff is exponential
from 500 ms.- Network failures are retried on the same schedule, then surface as a runtime error (exit
1).
Don’t wrap your own retry loop around write calls — a retried POST can double-create. Verify with
a follow-up GET instead. Rate limits documents the API-side windows.
Teams and impersonation
Requests carry the team header from --team-id → REPLY_TEAM_ID → the profile’s pinned team. If a
call needs a team and the credential spans several, the API returns TEAM_REQUIRED and the CLI adds
a one-line fix-it hint on stderr. Pin one non-interactively:
With an organization API key, name the acting user
with --user-id <id> or --user-email <email> (which also needs a team id). Pass exactly one.
These are flag-only — never read from the environment, never written to disk — so an agent must
supply them per invocation:
Rejection codes for organization keys are listed under
Rejection responses.
Safety is the caller’s job
The CLI has no --dry-run and no confirmation gates. reply api sends exactly the request you
give it — a DELETE deletes, and a POST /v3/sequences/{id}/start begins real outreach. The only
interactive prompt in the whole CLI is reply profile delete, which -y skips.
reply api owns the guardrails the platform safety rules
describe: confirm high-stakes actions with the user first, echo the exact request you’re about to
send, and prefer a read-back over a retry. Two habits that help:
- Resolve ids with a
GET before mutating; never invent numeric ids.
- Use
--verbose while developing a call — it prints the full request and response to stderr with
credentials redacted, leaving stdout pipeable.
Non-interactive environments
CI and agent sandboxes have no browser, so reply auth login won’t work. Supply a key instead:
Add -q/--quiet to silence progress messages on stderr; warnings and errors are still printed.
REPLY_CONFIG_DIR relocates the credential store when the default home directory isn’t writable.
Composition patterns
The CLI composes with cron for scheduled jobs, jq for filtering, and the
Reply Skills for procedure — the skill supplies the plan, the CLI executes it.
Install them with reply skills install.
Drop-in prompt
A ready-to-paste system prompt encoding this contract lives at
Drop-in system prompts → CLI variant. 
