JB

Project 02 · 2026

HookIt

A webhook delivery platform with at-least-once guarantees: failed deliveries retry on exponential backoff, exhausted ones land in a dead-letter queue for one-click redrive, and every payload is HMAC-signed with replay protection — all coordinated through PostgreSQL, no external broker.

PythonFastAPIPostgreSQLSQLAlchemyAlembicDockerFly.io

Deep-dive video — coming soon

HookIt

Highlights

  • At-least-once delivery with exponential backoff and jitter (10s → 1hr cap, 6 attempts), then dead-lettering with one-click manual redrive — no event is ever silently dropped.

  • Postgres as the queue — event rows, delivery rows, and the idempotency record commit in one transaction, and SELECT … FOR UPDATE SKIP LOCKED lets concurrent workers claim disjoint batches safely.

  • Idempotent ingestion with row-level locking and transactional deduplication, so duplicate requests and competing workers resolve to exactly one persisted event.

  • Secured end-to-end — HMAC-SHA256 signing with timestamped replay protection, SHA-256-hashed API keys, Fernet-encrypted secrets at rest, and SSRF-aware endpoint registration.

  • 298 tests exercising the API, worker, and a real Postgres instance together in CI on every PR.

Why I built it

Apps need to tell other apps when something happens — "a customer paid," "an order shipped." Sending that notification once and hoping isn't enough: receivers go down, time out, or get overloaded. HookIt sits in between and makes delivery something you can actually rely on.

The core design decision is Postgres as the queue instead of a broker like Redis or SQS. The event, its delivery rows, and the idempotency record all land in a single transaction, so nothing can be stored without being enqueued. Workers claim batches with SELECT … FOR UPDATE SKIP LOCKED, which lets any number of them run concurrently without ever grabbing the same delivery twice.

HookIt promises at-least-once, not exactly-once — an HTTP ack can be lost even after a successful POST, so chasing exactly-once over webhooks is impractical. Instead it retries with exponential backoff plus jitter (so a mass outage doesn't resynchronize into a thundering herd) and lets receivers deduplicate on stable event IDs.

Try it live

The hosted instance delivers real crypto-price events into a real Discord channel. From the dashboard you can take the receiver down and watch retries back off, deliveries dead-letter, and a redrive bring everything home — on live traffic.