Advanced usage

Everything here is the CLI doing work you would otherwise do by hand: proving a deploy is healthy, producing a report, or telling you which of seven possible things is broken.

In a pipeline

There is no browser in CI, so the key comes from the environment. Every command reads WAJUB_API_KEY when no profile is configured.

#!/usr/bin/env bash
set -euo pipefail

export WAJUB_API_KEY="$WAJUB_SANDBOX_KEY"   # from your CI secret store

# Fail the job if the key, the network or the account is wrong
wajub doctor --json > doctor.json

# Fail the job if the webhook endpoint disappeared
wajub webhooks list --json \
  | jq -e '.items[] | select(.url == "https://example.com/webhooks/wajub")' > /dev/null

--json on every command makes the output parseable, and jq -e turns "no match" into a non zero exit status, which is what makes the step actually fail.

Reports from the terminal

The list commands plus jq replace a lot of small scripts.

# Yesterday's failures, with the reason
wajub payments list --status failed --since 2026-01-14 --until 2026-01-14 --json \
  | jq -r '.items[] | [.created_at, .id, .amount, .currency, .failure_reason] | @tsv'

# Payouts still not settled
wajub transfers list --status processing --json \
  | jq -r '.items[] | [.id, .amount, .currency, .created_at] | @tsv'

Remember that --since and --until are whole calendar days. For a shorter window, filter the timestamps in jq after listing the day.

Talking to another host

--api-base points a command at a different API. It is how you drive a local platform, or a staging environment, without touching your profiles.

wajub doctor --api-base http://api.wajub.test
wajub payments list --api-base http://api.wajub.test --limit 5

For something you use daily, make it a profile instead, so you never forget the flag.

wajub config set local \
  --base-url http://api.wajub.test \
  --secret-key sk_test.mT9xW2kQ7vB4nL6hR1cY8dF3jS5aG0eU2pA…

wajub payments list --profile local

Shell completion

wajub autocomplete

It prints the two lines to add to your shell profile, for bash, zsh or fish. Worth the minute: ninety one commands is more than anyone remembers.

Starting from a working example

$ wajub samples --list

Available samples:
  webhooks               Minimal webhook receiver with signature verification (Node.js, no dependencies)

$ wajub samples webhooks my-receiver

The webhook sample is deliberately dependency free, so you can read the whole verification in one file rather than through a framework.

Jumping to the Dashboard

wajub open              # the dashboard home
wajub open payments
wajub open keys

The pages it knows are balance, customers, dashboard, disputes, keys, payments, refunds, settings, transfers and webhooks.

When something is wrong

Three commands, in increasing order of how much they tell you.

$ wajub version
@wajub/cli/1.4.0 darwin-arm64 node-v22.11.0

$ wajub status
● Wajub API is reachable, https://api.wajub.com (HTTP 200)

$ wajub doctor
Wajub CLI diagnostics
  …seven checks, in order

status answers "is it them or me" and needs no credentials. doctor answers "which of my seven things is broken" and ends with a request id to hand to support.

An unknown command fails clearly rather than doing something surprising.

$ wajub payment

 ›   Error: "payment" is not a wajub command. Run `wajub help` for the list.

Telling us what is missing

wajub feedback

It opens the feedback form in your browser. Pair it with the request id from wajub doctor and the first two messages of a support thread are already answered.