Test locally

Start your receiver

Run your application with a POST route, for example http://127.0.0.1:4242/webhooks. Implement signature verification and durable acceptance.

Sign in with a staging API key

listen and trigger need webhook access, which browser sign-in does not grant. Use a staging rk_sandbox_* secret key:

revkeen config set environment staging
revkeen login --api-key

Start listening

revkeen listen --forward-to http://127.0.0.1:4242/webhooks --events invoice.paid,payment.succeeded

The CLI prints a signing secret for this session. Give it to your receiver as REVKEEN_WEBHOOK_SECRET without committing it or pasting the terminal output into a ticket. Each forwarded request carries an X-Revkeen-Signature header in the standard format. The secret changes every time listen starts: update your receiver after a restart. Do not disable signature verification to troubleshoot a mismatch.

Send a test event

In a second terminal, signed in to the same merchant:

revkeen trigger invoice.paid

trigger sends a fixture to your listen session only. It creates no invoice and moves no money. The fixture carries triggered: true, so your receiver can tell it apart from a real event. The listen terminal shows the event type and your receiver's HTTP status.

Stop

Press Ctrl+C. listen forwards only while it runs: it does not queue or replay events that occur while it is stopped.

Start the application

Run your application on port 3000 with a POST route at /webhooks/revkeen. Implement signature verification and durable acceptance.

Open an HTTPS tunnel

Use your organisation's approved tunnel provider to forward to http://localhost:3000. Keep it running. Append /webhooks/revkeen to its public HTTPS address. The address may change when the tunnel restarts.

Register the staging endpoint

Follow endpoint setup using the tunnel URL. Store its signing secret locally as REVKEEN_WEBHOOK_SECRET, outside source control. Restart the application if it reads environment variables only at startup.

Verify delivery

Use the dashboard test action. Inspect the HTTP status and check that your receiver accepted the event durably before returning 2xx. Log IDs, timing, and status; keep secrets and customer payloads out of shared logs.

Exercise recovery

In your own test harness, simulate unavailable inbox storage and return 503. Restore storage and confirm a retry is accepted once. Send a duplicate signed fixture to verify that it does not repeat the business operation. Keep signature verification enabled.