Hook, Line & Sender

Problem & audience

Webhook delivery can fail temporarily. A relay needs to retain accepted events, track retries and make delivery outcomes inspectable instead of silently losing messages.

A developer exploring reliable event delivery between a producer and a configured local demo receiver.

My role

Independent project developer, implementing event acceptance, persistence, signed delivery and the activity dashboard.

• Python
• FastAPI
• PostgreSQL
• Celery
• Redis
• SQLAlchemy
• HTTPX

Implemented features

• Receives and persists webhook events before acknowledging acceptance.
• Delivers messages to one configured receiver with HMAC-SHA256 signatures and bounded retries for temporary failures.
• Records delivery attempts and exposes activity and attempt details in a dashboard.

Engineering decisions

• Uses PostgreSQL as the delivery source of truth and Celery/Redis for asynchronous tasks.
• Retains the serialized request body for retries and uses leases and terminal-state checks when claiming delivery work.
• Documents at-least-once delivery rather than promising exactly-once processing or ordering.

Testing & validation

• The repository includes a pytest suite, with separate PostgreSQL-marked tests requiring a real database.
• CI documents a non-PostgreSQL test command and database-backed validation.
• During this update, an isolated PostgreSQL/Redis/local-receiver demo delivered a synthetic event after two simulated HTTP 503 responses and a final HTTP 200. The full pytest suite was not rerun.

Current scope & limitations

• Current scope is a local portfolio project with one destination and API key, not a production-ready enterprise relay.
• CMS integrations, fan-out and manual replay are not implemented.
• No guaranteed ordering or exactly-once delivery; receivers must account for duplicate delivery.
• No runtime AI or LLM integration.