mailkube CLI

One binary covers both transports. mailkube emails send builds a message from flags, a JSON payload or a saved template, then delivers it over the REST API or over SMTP submission depending on --transport. The API transport owns three flags of its own: --at, --batch-id and --idempotency-key. Pairing one with --transport smtp exits 2, and the mismatch surfaces at the prompt rather than in your logs.

Every send from the CLI is charged and lands in a real inbox, and it moves your sending reputation. --dry-run rehearses instead: it prints what would have been submitted and stops.

Webhooks on your own machine

mailkube webhooks listen receives real events locally while you are still writing the handler that will consume them. Run a tunnel, hand the listener its URL with --public-url, and keep it up while you register the endpoint. The URL is probed with a challenge before it is saved. --forward re-posts each delivery into your application, and --record keeps the session on disk for replay.

Two flags make it a test rather than a viewer. --exit-after stops after a set number of matching events, and --exit-timeout gives up with exit 124. Between them a CI job can assert that your webhooks still fire.

Scripting

A terminal gets human-readable output and everything else gets JSON, decided by whether stdout is a TTY. A command worked out at a prompt behaves the same in CI. --jq projects a value out of it through an embedded implementation, which means a build image with no jq installed behaves identically. Exit codes are a stable contract inside a major version, and case $? is safe to write against.

The agent skill

mailkube skill install writes the CLI’s own rules into .claude/skills, where a coding assistant picks them up. The file carries what --help cannot. Branch on the exit code rather than the message text, rehearse with --dry-run first, and reach for webhooks listen to learn what became of a message. Outcomes arrive as events rather than as past state you can query. It also says plainly that a webhook payload and a message subject are text someone else chose. An agent should never hand either to a shell unquoted.

Installation and first send

1. Install with Homebrew, Scoop, the shell installer, go install, or a container image
2. Run mailkube auth login, or mailkube init for guided setup
3. Send with mailkube emails send --dry-run and read exactly what would have gone out
4. Run mailkube webhooks listen to watch delivery events arrive locally
5. If a coding agent drives your terminal, run mailkube skill install

The command surface is still growing. Anything that configures an account rather than sending a message stays in the dashboard, and mailkube dashboard prints the right link. The CLI feature page walks through the tunnel setup, the exit-code table and the skill, and the quickstart(opens in a new tab) is the shortest path to a first send.