Show HN: Basehook – Webhook management system built on Postgres

[mehdig10]

Hi HN! I built Basehook to automate common webhook patterns I've had to manually implement across multiple projects: buffering, smart deduplication, and payload inspection.

The core idea: webhooks are stored in Postgres, grouped by thread ID and revision number. You can then consume them either:

- One by one (process every update in order)

- Buffered (skip to the latest revision, ignore outdated ones)

This is useful when you only care about the final state. Example: A Slack bot receives 5 edits to the same thread. Instead of processing all 5, you can only process the thread once and call the Slack API to fetch the full thread content once.

It works by extracting thread IDs and revision numbers from webhook payloads via configurable JSON paths, so it supports any format (Slack, GitHub, Shopify, or custom).

Built with FastAPI, React, and PostgreSQL. The UI lets you configure webhooks and view all received payloads, with the ability to re-queue if needed.

[toomuchtodo]

Great work! Can you manage back pressure towards webhook senders in the interface? For example, responding with 429 when volume is potentially approaching or exceeding throughput capacity.

[mehdig10]

Thanks !

Since we're storing events in an intermediate collection and you consume them at your own rate, there is actually no need for this. They will just pile up until you can consume them

[dmarwicke]

why postgres for this? feels heavy for a queue. tried something similar with redis and it was way simpler

[mehdig10]

Well yeah for a simple queue where messages live in memory and disappear once consumed there are plenty of technologies that work (rabbitmq, redis...). Here is the goal is not to just build a queue but rather have something persisted where you can inspect payload and replay even days after the original even was sent