Skip to main content
jetemail resolves the API key in this order. First match wins.
  1. --api-key api_… (and --transactional-key transactional_…) flag
  2. JETEMAIL_API_KEY / JETEMAIL_TRANSACTIONAL_KEY environment variables
  3. Saved config (jetemail login writes here)
This precedence lets you keep a personal key in login for everyday use, override it temporarily on the command line, and switch to a CI-scoped key via environment variables in pipelines.

login

Interactive flow:
  1. Prompts for your api_… key.
  2. Validates it by calling GET /outbound/domains.
  3. Asks whether to also save a transactional_… key (used for email send / email batch).
  4. Writes both to the config file.
Non-interactive:
Skip the network round-trip with --skip-validation if you’re somewhere with no network access during setup.
Management endpoints (/outbound, /inbound, /webhooks, etc.) require an api_… key. The transactional send endpoints (/email, /email-batch) require a separate transactional_… key. The CLI picks the right one for you per command.

whoami

Prints which key is in use (masked), which layer it came from (flag, env, config), and re-validates against the API.

logout

Clears both keys from the config file. Your base_url override (if any) is preserved.

Non-interactive contexts

For CI, cron, scripts, AI agents, set the environment variables and skip login entirely:
Stdout stays clean JSON when stdout isn’t a TTY, so it pipes into jq, log collectors, and other tools without extra flags.

doctor

Reports config file location, presence of each key, the layer each came from, and whether the API is reachable with the active key. Non-zero exit if any required check fails.

Next: Config file

Where the config lives and how to edit it.