Claim Chaser Docs
Claim Chaser CLI — Onboarding Guide
Who this is for: developers and partners who prefer a command-line workflow to raw HTTP. The CLI wraps the same endpoints as the API onboarding guide — same journey, same soft-match contract, same guardrails. Every command and flag below is grounded in the shipped CLI source (claim-chaser-cli).
1 · Install & authenticate
The CLI is the claim-chaser-cli package; its binary is claim-chaser (built to dist/index.js). Build it from the repo (npm install && npm run build in claim-chaser-cli/), then invoke the claim-chaser bin — or run it directly with node dist/index.js.
The CLI authenticates with an API key — no email/password, and no local database configuration needed on your machine:
export CLAIM_CHASER_API_KEY="cc_live_YOUR_KEY_HERE"
# Base URL defaults to https://app.claimchaser.ai.
# Override with CLAIM_CHASER_BASE_URL, or the global --base-url flag.
When CLAIM_CHASER_API_KEY is set, every request rides the dedicated x-api-key header; the CLI never touches the interactive login path.
Verify the key works with any keyed read — for example:
claim-chaser carriers list --output json
⚠️
whoamiis not key-aware.claim-chaser whoamiruns the interactive JWT login path (CLAIM_CHASER_EMAIL/CLAIM_CHASER_PASSWORDor a stored session) and will report "Not logged in" under pure API-key auth. To confirm a key, run a keyed read likecarriers listordoctors list, notwhoami.
- The key's scopes govern what the CLI can do:
readfor reads,writefor provisioning + credentialing,calls:writefor dialing. - Key minting/revocation and webhook management stay in the Developer tab — the CLI can't manage keys.
Global flags (apply to every command)
| Flag | Effect |
|---|---|
--output <json|table> | Output format. |
--fields <a,b,c> | Restrict output to these fields. |
--base-url <url> | Override the API base URL. |
--verbose | Print the HTTP request/response. |
--dry-run | Validate a mutation without executing it (prints the body it would send). Read commands ignore it. |
2 · Command groups — mirroring the API journey
Each group wraps the corresponding endpoint. The provisioning order is the same as the API guide: office → doctor → carrier → credential → claims → callable.
2.1 · offices — create-or-match (scope: write)
Create first; doctors reference an office.
claim-chaser offices create \
--name "Main Street Clinic" \
--address "123 Main St" \
--callback-number "2085551234" \
--ein "123456789"
- Flags:
--name,--address,--ein,--callback-number, plus--resolve-to <id>and--create.--json '<body>'sends a full request body and overrides the individual flags. - Soft-matched: an exact name auto-matches and returns the existing office's id; an ambiguous name returns candidates — resolve with
--resolve-to <id>(which also teaches the mapping) or force a new record with--create. EIN only ever surfaces candidates — it never auto-links. claim-chaser offices list— lists offices in your org (GET /api/offices).
2.2 · doctors — create-or-match (scope: write)
claim-chaser doctors create \
--name "Dr. Smith" \
--npi "1234567890" \
--office-id "OFFICE_ID"
- Flags:
--name,--npi,--office-id, plus--resolve-to <id>and--create.--json '<body>'overrides the individual flags. - NPI (10 digits) is the strong identifier — an exact NPI hit auto-matches, org-scoped, before name matching. A name in the ambiguous band returns candidates; resolve with
--resolve-to <id>(teaches the mapping) or force with--create. --office-idmust belong to your org — a foreign id is a 404.claim-chaser doctors list— lists doctors in your org (GET /api/doctors).
2.3 · carriers — browse & request (scope: read / write)
claim-chaser carriers list --search "acme" # browse/search the catalog (read)
claim-chaser carriers request "Acme Health" # match-first request (write)
carriers listtakes an optional--search <text>(case-insensitive name substring). Returns each carrier with a per-orgin_networkannotation; internal/dev-only carriers are excluded.carriers request <name>takes the carrier name as a positional argument (not a flag), plus optional--phoneand--address(pre-populate the carrier on approval). Match-first: an exact catalog hit returns the existingcarrier_idimmediately and files nothing; a miss files a pending request for staff review, and thecarrier.request_resolvedwebhook fires when it's provisioned. Carrier creation is request-only — never direct.
2.4 · doctor-carriers — credential (scope: write)
claim-chaser doctor-carriers link DOC_ID CARRIER_ID
# actor kind defaults to 'customer'; pass --kind admin for staff
linktakes two positional arguments —<doctorId> <carrierId>— not--doctor-id/--carrier-idflags. It wrapsPOST /api/doctor-carriers/turn-on, which creates or re-activates the (doctor, carrier) credentialing link (idempotent — safe to call twice).--kindsets the actor recorded on the link and defaults tocustomer(the value for keyed/self-serve callers; staff useadmin). The API requires it; the CLI always sends it.- Foreign
doctor_id/carrier_id(belonging to another org) is refused by the org-ownership gate (404). claim-chaser doctor-carriers list— lists the links in your org (GET /api/doctor-carriers). Only credentialed (doctor, carrier) pairs are ever dialed.
2.5 · claims — inspect (scope: read)
claim-chaser claims get <claim-id> # claim details
claim-chaser claims statuses <claim-id> # status history
claim-chaser claims denial-reasons <claim-id> # extracted denial reasons
Claims upload is not a CLI command. The CLI has no wrapper for
POST /api/uploads/claims— upload claims via the API (see the API guide §6) or in the app. Theclaimsgroup here is inspect-only (plus thecallablecheck below and theupdate-denial-reasonsmutation).
2.6 · claims callable — always a dry run (scope: calls:write)
The callability check never dials and never bills — it is the CLI face of make-call with dry_run: true, and it always sends dry_run: true regardless of the global --dry-run flag.
claim-chaser claims callable <claim-id>
- Reports every dispatch blocker for the claim right now:
would_dispatch/would_be_blockedwithdispatch_blockers(e.g.VOICE_OFF,HOLIDAY_WEEKEND_FLOOR), or a422missing: […]list telling you why a claim can't be called. No call is placed; nothing is billed. - There is no "actually dial" mode on
claims callable— by design, a partner cannot accidentally bill from the callability check.
2.7 · Real dialing — calls make (scope: calls:write)
Real dialing is a separate, explicit command. It counts against the key's daily call cap and needs calls:write.
claim-chaser calls make --claim-id <claim-id> # real dispatch — dials and bills
- Add the global
--dry-runto rehearse without dialing (equivalent toclaims callable). - Related reads:
calls list [--status active|recent|all] [--limit N] [--page N],calls get <id>,calls check-status <id>,calls stats.
3 · Full journey
export CLAIM_CHASER_API_KEY="cc_live_YOUR_KEY_HERE"
# 1. office (first — doctors reference it)
claim-chaser offices create --name "Main Street Clinic" --address "123 Main St" --callback-number "2085551234" --ein "123456789"
# 2. doctor (link to the office_id from step 1)
claim-chaser doctors create --name "Dr. Smith" --npi "1234567890" --office-id "OFFICE_ID"
# 3. carrier — match-first; use the returned carrier_id, or wait for carrier.request_resolved
claim-chaser carriers request "Acme Health"
# 4. credential the pair (positional doctorId carrierId; kind defaults to 'customer')
claim-chaser doctor-carriers link "DOC_ID" "CARRIER_ID"
# 5. upload claims — via the API/app, not the CLI (no CLI upload command)
# 6. confirm callable (always a dry run: no dial, no bill)
claim-chaser claims callable "CLAIM_ID"
For every exact field, status code, and error body, the API Reference at /docs/api-reference is the contract — the CLI is a thin wrapper over the same endpoints the API guide documents.