/nansen-alerts-webhook-listener

name: nansen-alerts-webhook-listener
description: Set up a local webhook server to receive Nansen smart alerts in real-time with HMAC signature verification and public tunneling. Use when a user wants to listen for alerts on their local machine.
metadata:
  openclaw:
    requires:
      bins:
        - nansen
        - node
    primaryEnv: NANSEN_API_KEY
    install:
      - kind: node
        package: nansen-cli
        bins: [nansen]
allowed-tools: Bash(nansen:*), Bash(node:*), Bash(npx:*), Bash(ngrok:*), Write

Authentication

Nansen account API calls accept a selected `nansen:api` browser session or conventional API key with the same permissions. `NANSEN_API_KEY` takes precedence; optional `primaryEnv` preserves configured-key injection. Run `nansen auth status` for offline selection. Cached access expiry alone permits automatic renewal during an authorized task. Stop on anonymous selection, invalid state, blocked/uncertain renewal or actual auth failure; never drop a credential or fall back to anonymous x402 payment. Browser login does not grant wallet signing, privileged service identity or a persistent MCP integration key. Preserve all confirmation, signing, sanctions and geographic checks below. Browser login is available in CLI 2.0.0 within the [macOS arm64 preview scope](https://github.com/nansen-ai/nansen-cli/blob/main/docs/browser-login.md#preview-platform-scope).

Alert Webhook Listener

Set up a local HTTP server to receive Nansen smart alert webhook payloads in real-time.

How It Works

Nansen smart alerts support a **webhook** channel type. When an alert fires, Nansen sends an HTTP POST with a JSON payload to your webhook URL. This skill sets up:

1. A local HTTP server (Node.js, zero external dependencies) that receives and displays alert payloads 2. HMAC-SHA256 signature verification so only authentic Nansen payloads are accepted 3. A public tunnel so Nansen's servers can reach your local machine

**This skill does NOT create or modify alerts.** It sets up the listener infrastructure and then provides a summary of what the user needs to do to start receiving alerts.

**OpenClaw users:** If OpenClaw is running locally on the same machine, the webhook server can forward verified alert payloads to OpenClaw's Gateway (`/hooks/agent`), triggering an agent turn for each alert. Set the `OPENCLAW_GATEWAY_URL` env var to enable this. See the **OpenClaw Integration** section below.

Security Warning

**Before proceeding, inform the user:**

> This skill starts an HTTP server on your machine and exposes it to the internet via a tunnel (ngrok or localtunnel). While the server only binds to localhost (`127.0.0.1`) — meaning no one on your local network can access it directly — the tunnel creates a public URL that **anyone on the internet** can send requests to. > > **Mitigations in place:** > - HMAC-SHA256 signature verification rejects all requests not signed by Nansen > - 1 MB body size limit prevents memory abuse > - Only `POST /webhook` and `GET /health` are accepted; everything else returns 404 > > **You should be aware that:** > - The tunnel URL is publicly discoverable (ngrok URLs can be enumerated) > - Unsigned requests still reach your machine — they're rejected, but the connection is made > - Stop the tunnel when you're done to close the public endpoint

Wait for the user to confirm they want to proceed before continuing.

Execution Plan

Follow these steps **in order**. Do not skip signature verification — it is mandatory.

Step 0: Choose a tunnel provider

Before starting, ask the user which tunnel provider they want to use:

| | **ngrok** (recommended) | **localtunnel** | |---|---|---| | Stability | Stable — persistent connections with keepalive | Flaky — free relay drops idle connections without warning, tunnels die randomly | | Install | `brew install ngrok` + free account at ngrok.com | Zero install (`npx localtunnel`) | | HTTPS | Yes | Yes | | Auth required | Yes (free authtoken from ngrok.com) | No |

**Recommend ngrok.** localtunnel is convenient but unreliable — in testing, tunnels silently exit after minutes, causing alerts to fail with "503 Tunnel Unavailable". ngrok maintains stable connections.

Check if ngrok is available:

which ngrok && ngrok version

If not installed, tell the user: 1. `brew install ngrok` (or download from ngrok.com) 2. Create a free account at ngrok.com and copy the authtoken 3. `ngrok config add-authtoken <token>`

If the user prefers localtunnel or can't install ngrok, proceed with localtunnel but warn them that the tunnel may drop and they'll need to restart it and update their alert's webhook URL.

Step 1: Generate a webhook secret

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

Store the output — you need it for both the server and the alert configuration. **Never log or echo the secret after this point.**

Step 2: Write the webhook receiver script

Create `nansen-webhook-server.mjs` in the current working directory. Use **only** Node.js built-in modules (`node:http`, `node:crypto`). No `npm install` required.

**Requirements — do not deviate:**

| Requirement | Detail | |---|---| | Bind address | `127.0.0.1` only — **never** `0.0.0.0` | | Default port | `9477` (override via `PORT` env var) | | Webhook path | `POST /webhook` — reject all other method/path combos with 404 | | Health check | `GET /health` → 200 `{"status":"ok"}` | | Signature verification | Verify `x-nansen-signature` header using HMAC-SHA256 with timing-safe comparison. Reject 401 on mismatch. | | Secret validation | Exit on startup if `WEBHOOK_SECRET` env var is missing or < 16 chars | | Payload logging | Pretty-print valid JSON payloads to stdout with ISO timestamp | | Request size limit | Reject bodies > 1 MB (413) to prevent memory abuse | | Graceful shutdown | Handle `SIGINT` and `SIGTERM` — close server, then exit | | OpenClaw forwarding | If `OPENCLAW_GATEWAY_URL` env var is