Skip to main content
wbhk is the webhook.co command-line client. It does everything the dashboard does — create endpoints, inspect events, stream deliveries to your machine, replay them to localhost, manage destinations and agent triggers — and it does it in a form you can pipe into jq and drop into a script.

Install and sign in

Then authenticate:
login runs a browser OAuth flow by default, validates the minted credential, and stores a short-lived, scoped key in your OS keychain. From there the CLI refreshes the access token silently — you stay logged in without a long-lived secret sitting on disk.

Installation channels

Every channel lands the same wbhk binary or package. Every release is built in CI with sigstore-signed build provenance, so a downloaded binary is independently verifiable — the provenance proves it was built from this repository’s GitHub Actions, not hand-uploaded. Verify a binary with gh attestation verify, or check an npm install with npm audit signatures.

Signing in

wbhk login supports three credential flows. All of them validate the credential before anything is written, so a bad key stores nothing. The key is never taken as a command-line argument — that would leak it into your shell history and the process list. It comes from a hidden prompt or stdin. wbhk logout clears the stored credential. For an OAuth credential it also revokes the token server-side, so a logged-out session stops working everywhere — not just on this machine.
Credentials go into your OS keychain when one is available. On a box without a keychain helper, wbhk login --insecure-storage falls back to a 0600 config file. wbhk doctor tells you which backend is in use.

Global flags

Every command accepts the same four global flags.

Profiles for multiple accounts

A profile is a named credential plus its base URL — keep a work org and a personal org side by side.
Profile selection resolves in order: --profile beats the WBHK_PROFILE env var, which beats the persisted active profile, which falls back to default. When a command runs against a non-default profile, wbhk prints a one-line stderr banner so a run against staging or prod never surprises you.

Diagnostics, updates, telemetry

  • wbhk doctor runs local, silent checks and reports the CLI version, active credential and its source, config-file health, API reachability, and clock skew. It exits non-zero only for a must-fix local misconfiguration (a corrupt or world-readable config); transient things stay warnings.
  • wbhk upgrade updates a standalone binary in place after verifying the download’s checksum and build provenance; --check just reports whether an update is available. A package-managed install is detected and pointed at its own updater.
  • Update notices. When a newer wbhk exists, the CLI shows a one-line boxed notice on stderr and points you at wbhk upgrade. It costs nothing and makes no extra network request: the CLI sends its version with the API calls you were already making, and the server answers on those same responses. The notice is cached, so even wbhk -v — which makes no request at all — can tell you. It is suppressed for --output json, for non-interactive shells (a nudge must never pollute a script), and entirely by WBHK_NO_UPDATE_CHECK=1.
  • wbhk telemetry status / off manages anonymous, opt-out usage telemetry — which commands ran, the CLI version, and OS/arch, never your data or credentials. Off automatically in CI, or set WBHK_TELEMETRY=0.
  • wbhk completion bash|zsh|fish prints a shell tab-completion script to standard output; save it and source it from your shell config. Completions defer to wbhk itself, so they always reflect the live command set.

Next