Hookie

Overview

The Problem

Webhook development gets awkward once more than one person, environment, or agent needs the same events. A sender usually accepts one destination URL per registration. Every new tunnel creates another URL, another shared secret, and another place to clean up when a developer changes projects.

Tunnels are fine for individual debugging. They get noisy when a team needs the same Stripe, GitHub, or internal webhook stream and each laptop has a different public endpoint. Missed events are hard to replay, visibility lives on one machine, and local code has to be reachable from the internet.

The bet

Keep the public webhook surface centralized, then let developers and agents attach their working environments without touching sender configuration.

What I Built

• A Go ingest service that accepts webhook HTTP requests and publishes events into Redis Streams
• A Go gRPC relay that streams events from Redis to connected developer and agent environments
• A Next.js app for apps, topics, auth, and the dashboard, backed by Clerk and Supabase
• A Go CLI that can log in, list apps and topics, listen anonymously or by app/topic, and forward events to a local HTTP endpoint

The Tradeoff

Hookie is deliberately narrow: a relay for development environments, not a production ingress platform with delivery policy, operator dashboards, or commercial SLAs. That scope kept the project shippable without turning webhook delivery into the whole product.

The relay inverts the ngrok model (one public URL, many consumers), which solves team-scale and agent-scale webhook sharing. It does not yet solve replay for disconnected CLIs, rich observability, or production-grade retry semantics.

Where It Landed

I dogfooded the fan-out model with an incident response team using real PagerDuty and Slack traffic. My friend Cody collaborated on Hookie; I owned the design and operated the relay for that rollout. One ingest URL per source was enough for the whole team: everyone who ran hookie listen received the same payloads and headers without per-person tunnel URLs or extra webhook registrations in those products.

I did not run formal benchmarks or keep publishable metrics for that rollout. The evidence was operational: shared registrations, less URL churn, and configuration that stayed O(platforms) as more developers joined instead of O(developers × platforms).

The deeper architecture notes live in the paired technical post.

technical notes

I moved the relay architecture, protocol, and backpressure details into the article so this portfolio page stays focused on the product shape and outcome.

Where It's Going

The product thesis is multiplayer webhooks for the AI-native dev workflow: one URL, broadcast to every environment you and your agents work in. Hookie is scoped around development and debugging, not production delivery.

The website and docs are the public reference for webhook ingest, fan-out, and local delivery.

status

The Hookie website and docs remain public. The repository is private.

• Developer tools
• gRPC
• Webhooks