Scripting
--json, stdout vs. stderr, and exit codes — how to drive the CLI from another program.
Last updated on
Every command takes --json. It prints machine-readable JSON on stdout and skips all interactive rendering — no Ink, no colour, no spinners.
postonus queue list --json | jq -r '.queue[] | "\(.scheduledAt) \(.platform)"'stdout carries data, stderr carries progress
Data goes to stdout. Progress lines and hints ("Uploading demo.mp4…") go to stderr. A pipe only ever sees the data:
postonus post --file draft.md --to linkedin --at 2026-08-01T09:30:00Z --json-q, --quiet suppresses the stderr progress lines without switching to JSON, for when you want the human-readable stdout output but no chatter.
Exit codes
| Code | Meaning |
|---|---|
0 | Success. |
1 | The command ran but failed — a rejected request, a missing file. |
2 | Usage error — a missing or unparseable argument. Also what postonus --help exits with. |
An error is written to stderr as Error: <message>. In --json mode it is written to stdout instead, as { "error": "<message>" }, so a script gets a parseable result on either path.
No TTY means no prompts
With no terminal attached (piped input, CI), the CLI never prompts, spins, or colours output — pass the flags a prompt would have asked for instead. --no-input makes this explicit: a command that would need to prompt fails immediately with a message telling you which flag to pass, rather than hanging on a read that will never arrive.
--no-color turns off colour even in a real terminal; NO_COLOR (any value) does the same from the environment.
Piping content in
cat draft.md | postonus post --to x --optimalOnly used when no --file, --editor, or positional text is given, and only when stdin is not a TTY.
Dry-running a post
postonus post "test" --to x --optimal --dry-runResolves channels and prints what would be scheduled — content, target channels, timing — without creating anything.