Use Cases

What you can build with Anonymily

From local development to team debugging to AI-assisted diagnosis — here are the problems Anonymily solves and how to set each one up.

Local developmentCI / staging pipelinesDebugging production eventsHandler developmentTeam webhook sharingAI-assisted debuggingPRO

Local development

Receive real provider events on localhost without ngrok, port forwarding, or firewall rules.

CLI relayNamed endpointSignature verify
The problem

Webhook providers need a public HTTPS URL. Your dev server lives on localhost. The usual fix — ngrok, Serveo, localtunnel — punches a tunnel through to your machine, exposing your full server to the internet.

The solution

Anonymily flips the model. Your CLI pulls events from our edge; nothing inbound ever reaches your machine. The relay URL is stable (named endpoints stay the same across restarts), so you paste it once into Stripe or GitHub and forget it.

bash
# start relaying to localhost:3000 with a stable named URL $ npx @anonymilyhq/cli listen 3000 --id stripe-dev --token $ANONYMILY_TOKEN 🚀 Anonymily CLI Endpoint → https://api.anonymily.com/h/stripe-dev Forwarding → http://localhost:3000 [10:14:02] ⚡ POST /h/stripe-dev payment_intent.succeeded → 200 OK

CI / staging pipelines

Run real webhook integration tests in CI without any external config changes per run.

Named endpointEvent historyReplay
The problem

Integration tests that depend on webhook delivery are brittle in CI: you either mock the provider (misses real edge cases) or set up a publicly reachable staging server (slow, stateful, expensive).

The solution

Point your provider's staging config at a permanent named Anonymily endpoint. CI starts the relay, runs the test suite, and the events flow through — captured and inspectable long after the build finishes. Failed runs? Replay the exact event that broke things.

github actions
- name: Run webhook integration tests env: ANONYMILY_TOKEN: ${{ secrets.ANONYMILY_TOKEN }} ANONYMILY_HOOK_ID: stripe-staging run: | # relay events to the test server running in CI npx @anonymilyhq/cli listen 4000 & npm run test:integration

Debugging production events

Replay the exact event that failed in production against a local debug build.

Event captureCLI replayDashboard search
The problem

A webhook fails silently in production. The provider's retry log gives you a status code but not the full request. You can't reproduce it locally because you don't know the exact payload.

The solution

Anonymily stored the raw event — headers and body — when it first arrived. Find it in the Dashboard, copy the event ID, and replay it locally. Same bytes, same signature, same conditions.

bash
# find the failed event ID in the Dashboard, then: $ npx @anonymilyhq/cli replay evt_9kfz3mN --port 3000 Replaying evt_9kfz3mN → http://localhost:3000 Method : POST Path : /webhooks/stripe Headers: stripe-signature, content-type, … ← 500 {"error": "missing idempotency key"} ← reproduced locally ✓

Handler development

Iterate on webhook handlers with real events and instant feedback — no provider dashboard needed.

Synthetic eventsResponse captureProvider presets
The problem

Writing a new webhook handler means toggling between your editor, the provider dashboard, test-event forms, and your terminal. Every iteration is three windows and a context switch.

The solution

Fire test events from the Anonymily Dashboard or CLI — pre-filled for Stripe, GitHub, Shopify, or Slack. Watch the response status and body your local server returned. Iterate without leaving your terminal.

bash
# fire a Stripe payment_intent.succeeded test event $ npx @anonymilyhq/cli fire stripe payment_intent.succeeded --port 3000 ⚡ Fired stripe:payment_intent.succeeded ← 200 {"received": true} # iterate — fire again after changing handler code $ npx @anonymilyhq/cli fire stripe payment_intent.payment_failed --port 3000 ← 500 {"error": "unhandled event type"} ← found the gap

Team webhook sharing

Multiple engineers watching the same live hook — useful for pair-debugging or onboarding.

ProTeam tierMultiple relays
The problem

Debugging a webhook integration as a team means one person shares their screen or copy-pastes payloads into Slack. Everyone else is flying blind.

The solution

On Pro, multiple CLI sessions can relay the same named hook simultaneously. Everyone sees the same live stream of events. One person can replay; another can inspect in the Dashboard. No coordination required.

bash
# engineer A — their machine $ npx @anonymilyhq/cli listen 3000 --id payments-hook --token $TOKEN [11:02:01] ⚡ POST payment_intent.succeeded → 200 # engineer B — simultaneously, same hook $ npx @anonymilyhq/cli listen 3001 --id payments-hook --token $TOKEN [11:02:01] ⚡ POST payment_intent.succeeded → 200 ← same event, different port

AI-assisted debugging

PRO

Diagnose failures, generate handler stubs, and produce edge-case test payloads — from any captured event.

ProAI diagnosisHandler genEdge-case events
The problem

A webhook handler fails on a rare event type you've never seen before. Reading the raw JSON and tracing the code path takes 30 minutes. Writing a realistic test payload for that edge case takes another 30.

The solution

Send the captured event to Anonymily's AI assistant. It diagnoses the failure (with line-level code context), generates a production-ready handler stub, and can synthesize a set of edge-case variants you can fire immediately.

dashboard — ai diagnosis
Event: stripe:charge.dispute.created 🤖 Diagnosis Your handler returns 200 but throws before writing to the database. The dispute reason "credit_not_processed" hits a missing switch-case branch in /webhooks/stripe.ts:87. Suggested fix: case 'credit_not_processed': await markChargeDisputed(charge_id, reason); break; Generate full handler? [Yes] Generate edge-case events? [Yes]
← ArchitectureGetting Started