I Built an AI-Native Webhook Inspector & Relay in 6 Weeks — Here’s What I Learned

I built an AI-native webhook inspector in 6 weeks — here's what I learned

Every developer has lost a webhook.

Your server restarts. Stripe fires a payment event. It vanishes. No log, no trace, no way to replay it. You find out two hours later when a customer complains their order wasn't processed.

I spent 3 hours debugging exactly this problem. The fix took 5 minutes. The debugging took 3 hours.

That was 6 weeks ago. I built Hookdropi to make sure it never happens again.

---

What I built

Hookdropi is an AI-native webhook relay and inspector. Here's what it does:

• Captures every webhook permanently one URL that never goes down, every event logged in full
• Forwards with auto-retry exponential backoff: 5s → 30s → 2m → 10m → dead letter queue
• One-click replay replay any past event against any environment instantly
• Live event stream WebSocket-powered real-time dashboard
• AI that explains payloads plain English explanation of what arrived and why
• Every developer has missed a webhook. Your server restarts mid-deploy. Stripe fires a payment succeeded event. Your endpoint is down Stripe retries on its schedule (hours later in live mode). The event doesn’t vanish. But without instant inspection or a reliable relay, it fails to process automatically. You only find out hours later when a customer complains their order wasn’t fulfilled. I spent 3 hours debugging exactly this problem. The actual fix took 5 minutes. The debugging took 3 hours. That was 6 weeks ago. So I built Hookdropi to make sure it never happens again. What I built Hookdropi is an AI-native webhook relay and inspector. Here’s what it does:

Captures every webhook permanently one URL that never goes down, every event logged in full
Forwards with smart auto-retry exponential backoff: 5s → 30s → 2m → 10m → dead letter queue
One-click replay replay any past event against any environment instantly
Live event stream WebSocket-powered real-time dashboard
AI that explains payloads plain English breakdown of what arrived and why
AI that writes handler code generates complete TypeScript, JavaScript, Python, or Go handlers
AI that diagnoses failures tells you exactly what broke and how to fix it

The tech stack
I wanted to build something real not a toy project. Here’s the full stack I used:
Backend:

Node.js + TypeScript across all three services
PostgreSQL 16 with TypeORM and hand-written migrations
Redis + BullMQ for the delivery queue
Express for both the ingestion API and dashboard API
Socket.io for the real-time event stream

Frontend:

Next.js 16 with the App Router
Tailwind CSS
Zustand for state management
Socket.io client for live updates

AI layer:

Google Gemini (gemini-3-flash-preview)
Results cached in an ai_insights table so the same payload is never analyzed twice

Payments:

Paystack (Nigeria-first)
Flutterwave (pan-Africa)
Multi-gateway provider pattern so adding Stripe later is just one new file

Infrastructure:

Railway for the three backend services
Neon for managed PostgreSQL
Upstash for managed Redis
Vercel for the frontend
Resend for transactional email
Sentry for error tracking
Mintlify for documentation

The architecture that surprised me most
I separated the ingestion API from the dashboard API. This was the best decision I made.
The ingestion endpoint needs to respond in under 50 ms. Stripe waits for your 200 OK. If you’re slow, they treat it as a failure and start retrying. By keeping ingestion separate from the heavier dashboard logic, I can scale them independently and keep p99 latency low.

The flow looks like this:
BashStripe → POST /in/:token
↓
Save event to Postgres (< 10ms)
↓
Enqueue BullMQ job (< 5ms)
↓
Emit Socket.io event (< 2ms)
↓
Return 200 OK (total: < 50ms)

The delivery worker picks up the job asynchronously and handles all the retry logic separately. The webhook sender never has to wait for delivery.
What I learned about BullMQ
I’d used simple job queues before but never dug into retry logic properly. BullMQ’s exponential backoff is elegant you configure it once and it handles everything:

TypeScriptawait deliveryQueue.add(
'deliver',
{ eventId: savedEvent.id, endpointId: endpoint.id },
{
attempts: 4,
backoff: { type: 'exponential', delay: 5000 },
}
)

That single configuration gives you: first retry at 5s, second at 25s, third at 125s, fourth at 625s. After 4 failures the job moves to the dead letter queue and the user gets an email.
The AI layer took one afternoon
I expected AI integration to be the hardest part. It was actually the easiest.
The key insight: prompt engineering matters more than model choice. My payload explanation prompt is just:
textYou are a webhook expert helping a developer understand an incoming webhook payload.
Explain this webhook payload in 2-3 plain English sentences. Be specific about what
event occurred, what triggered it, and what the key fields mean.
That’s it. Gemini does the rest. I cache results in an ai_insights table so the same payload is never analyzed twice important for cost control.
What I’d do differently

I’d build the delivery worker first. I built the ingestion API first, which felt logical. But the delivery worker is the core value of the product. Everything else is UI around it.
I’d set up monitoring on day one. I added Sentry and UptimeRobot late. Having visibility from the start would have saved me debugging time.
I’d deploy earlier. I spent too long perfecting things locally. The bugs you only find in production environment variables, CORS, Redis connection strings are best found early.

The result
Hookdropi is live. Free plan available. Here’s what you get:

500 events/month on the free plan
Paid plans start at ₦7,500/month (Starter) with AI features unlocked
Paystack and Flutterwave for African developers
Full API for programmatic access

Try it at hookdropi.qzz.io
Docs at bobprince.mintlify.app
Source on GitHub (link in bio / docs)
If you work with webhooks daily Stripe, GitHub, Paystack, Shopify I’d love for you to try it and tell me what’s missing.
Built in Nigeria 🇳🇬