slinghook CLI

Forwards webhooks captured by a SlingHook server to a server on your machine, such as localhost:3000. A hosted SlingHook instance can't reach your localhost, so the CLI makes the connection outbound, the same way stripe listen does.

Requires Node 20.17+.

npm install -g slinghook

slinghook auth login --server https://slinghook.co.za
slinghook auth status          # who you're logged in as
slinghook endpoints            # list your endpoint UUIDs
slinghook mcp                  # MCP server for AI agents (see below)
slinghook listen <uuid> --forward http://localhost:3000/webhooks
# <uuid> can also be the catch URL you copied, e.g. https://slinghook.co.za/c/<uuid>

Every command also works with the short name shk, e.g. shk auth login or shk listen <uuid> --forward …. login, status and logout also work without auth, as in earlier versions.

● Listening on endpoint 3f1c…
  Forwarding to http://localhost:3000/webhooks

14:02:11 POST   #1234 → 200 37ms sig:valid
14:02:15 POST   #1235 → ✗ Connection refused (is your local server running?) 2ms

How it works

1. Auth. slinghook login works like gh auth login. It asks how you want to log in:

   • Web browser. The CLI shows a one-time code (like BCDF-GHJK) and opens the dashboard. Sign in there however you normally do (password, Google, GitHub, SAML, two-factor) and approve the code. The CLI then receives a new API token named after your computer. The token works in the workspace you approved it from. --web skips the question. Codes expire after 15 minutes.
   • Personal access token. Create one under User Settings → API Tokens (/app/?settings=tokens) and paste it. In scripts and CI use slinghook login --with-token < token.txt, --token shk_…, or set SLINGHOOK_TOKEN.

   Only the token is saved, in ~/.config/slinghook/config.json (mode 0600). The server stores only a SHA-256 hash of it. You can see and revoke tokens under User Settings → API Tokens.

2. Stream. listen opens GET /v1/events/<uuid> with Authorization: Bearer <token>. This is the same SSE stream the dashboard uses. On first connect the server sends recent history, which the CLI skips. It forwards only new log events.

3. Reconnect. The server closes the stream every ~55s by design. The CLI reconnects with Last-Event-ID, so webhooks that arrive during the gap are delivered once and in order. Network errors back off from 1s up to 30s.

4. Forward. Each webhook is re-sent with its original method, body, query string, and headers. Hop-by-hop headers such as Host and Content-Length are dropped. Signature headers are kept, so your app's verification runs for real. The CLI adds X-Webhook-Replay: true and X-SlingHook-Log-Id. Deliveries run one at a time with a 15s timeout. Payloads that were truncated at capture are skipped. If your server is down, times out, or answers 408, 425, 429 or 5xx, the CLI retries 3 more times (after 1s, 2s and 4s) before moving on. Later webhooks wait, so they still arrive in order. --retries N changes the count (0 to 10).

5. Report. Each result is posted to POST /api/logs/<id>/replays, so it appears in the dashboard's replay history. Use --no-report to turn this off.

Team routing: one provider URL, many developers

On the Team plan, a whole team can share one endpoint (Stripe and Shopify only allow a few webhook URLs) and still each get their own events on their own machine. Claim the events that are yours, then listen with --mine:

# Events whose body has metadata.dev = "

... [View full README on GitHub](https://github.com/dylancourtney584/slinghook-cli#readme)