Webhooks that commit with your data.
A TypeScript library that queues webhooks in your Postgres transaction, then signs, retries and logs every delivery. No extra service, no per‑message bill.
-Add Hookgres webhooks to this app: hookgres.dev/llms.txt
-Webhooks that commit with your data.
npm install hookgres pg
--
@@ -813,19 +1217,175 @@
Webhooks that commit with your data.
when you need it
+“Can you tell our system when this happens?”
+When a customer asks that, you need webhooks. Six requests SaaS teams get most, each answered with one send() inside the transaction that saves the change.
-
+
-
+ LikeCal.com+
Bookings to their CRM
+A demo gets booked and lands in the customer’s sales pipeline.
+ +
+ -
+ LikeStripe+
Invoices to their ERP
+Their accounting system marks it paid only if your payment committed.
+ +
+ -
+ LikeReplicate+
Long jobs, no polling
+One request when the job finishes, instead of one every few seconds.
+ +
+ -
+ LikeTally+
Zapier, Make and n8n
+One webhook URL setting connects your product to thousands of apps.
+ +
+ -
+ LikeShopify+
Orders to their warehouse
+Each merchant adds its own endpoints and picks the events it needs.
+ +
+ -
+ LikeResend+
Email events to their app
+High-volume events, where a per-message bill grows fastest.
+ +
+
Only receiving webhooks from Stripe, GitHub or Clerk? You don’t need Hookgres. Their verification library is enough.
+ +hookgres.send()
+One commit in. Every endpoint, signed and retried.
+send() writes a row next to your data. After COMMIT, workers claim it with SKIP LOCKED, sign the request and deliver it to each endpoint. A failure goes back on the schedule.
Transactional
+BEGIN … COMMIT
Queued in your transaction. Sent only if it commits.
A webhook service is a second system. Call it after your commit, and a crash in between loses the event. Call it before, and a rollback leaves your customer with a webhook for an invoice that was never paid. Hookgres writes the webhook in the same transaction as your data, so you get the outbox and the delivery in one library.
-Workers claim deliveries with FOR UPDATE SKIP LOCKED, so you can run as many as you like.
On an ORM, pass its transaction instead. Adapters for Prisma and Kysely ship with Hookgres; Drizzle, postgres.js, Knex, Sequelize, TypeORM and MikroORM each take a tested wrapper of a few lines.
+await client.query("BEGIN");await client.query( ++ +-+-await client.query("BEGIN");await client.query( `UPDATE invoices SET status = 'paid' WHERE id = $1`, [id], @@ -833,49 +1393,87 @@-Queued in your transaction. Sent only if it commits.
tenantId, eventType: "invoice.paid", payload: { id }, -}, { client });await client.query("COMMIT");- - -Nothing is sent until the transaction commits.
+ +Nothing is sent until the transaction commits.
The bug it fixes
-A job queue can't roll back with your data.
-The same payment code, run twice. First it queues the webhook with BullMQ inside the transaction: the payment rolls back, but the job is already in Redis, so acme.com marks in_124 paid while your database says open. Any queue outside Postgres does the same. Then the queue is swapped for hookgres.send(), and the webhook rolls back with the payment. Real BullMQ, Redis and Postgres, played at 2× speed.
ROLLBACK
+A job queue can’t roll back with your data.
+A queue outside Postgres keeps a job your transaction rolled back, so your customer hears about a payment that never happened. Two terminal recordings with real Postgres and the published package.
The same payment code, run twice. With BullMQ, the payment rolls back but the job is already in Redis, so acme.com marks in_124 paid. With hookgres.send(), the webhook rolls back with the payment.
From npm install hookgres pg to a logged retry, against a receiver that is down for two attempts. The rolled-back invoice sends nothing; the committed one is signed, retried and logged.
Not a contrived example. Other teams hit these bugs in 2026:
-
-
-
-
“…the entire batch is rolled back, but the webhook for the earlier (now rolled-back) request has already been dispatched.”
- Apache Fineract, March 2026 + -
+ Apache FineractJira · FINERACT-2570Mar 2026+
“…the entire batch is rolled back, but the webhook for the earlier (now rolled-back) request has already been dispatched.”
+ Read it on issues.apache.org
- -
-
“REST API dispatches events for writes that were rolled back”
- NetBox, August 2026 + -
+ NetBoxGitHub · #22978Aug 2026+
“REST API dispatches events for writes that were rolled back”
+ Read it on github.com
- -
-
“If that process dies — for any reason — the webhook dies with it.”
- Dodo Payments, January 2026 + -
+ Dodo PaymentsEngineering blogJan 2026+
“If that process dies — for any reason — the webhook dies with it.”
+ Read it on dodopayments.com
Why the usual fixes close only one gap
@@ -883,182 +1481,177 @@Not a contrived example. Other teams hit these bugs in 2026:
Retries
-Watch it retry.
-Pick how your customer's server behaves and send an event. This runs the default schedule, with 28 hours squeezed into a few seconds.
-retry schedule · 0s → 27.6h
+Watch it retry.
+One invoice.paid, three of your customers’ servers. Each endpoint retries on its own schedule for up to 28 hours, here squeezed into a few seconds.
over about 28 hours, from 5 seconds to 10 hours apart.
of failures before an endpoint is disabled. One call turns it back on.
when old and new secrets both sign, so receivers rotate without dropping events.
and none duplicated across 20,000 webhooks and 4 competing workers in the load test.
over about 28 hours, from 5 seconds to 10 hours apart.
of failures before an endpoint is disabled. One call turns it back on.
when old and new secrets both sign, so receivers rotate without dropping events.
and none duplicated across 20,000 webhooks and 4 competing workers in the load test.
The same retry shape Svix uses, all configurable. On one laptop: about 13,000 sends and 5,500 deliveries per second. Reproduce it with pnpm bench.
Signatures
-What your customers receive.
-A JSON envelope and three signed headers. The webhook-id stays the same across retries. Delivery is at least once, so receivers deduplicate on it.
Verify in any language with the official Standard Webhooks libraries: JavaScript, Python, Go, Ruby, PHP, Rust, Java, C# and Elixir.
+standard webhooks
+Your customers verify it with code they already have.
+Every request is signed to the open Standard Webhooks spec. Your customers check it with an official library in their own language, so you never have to invent a signing scheme and support it.
+Official libraries for JavaScript, Python, Go, Ruby, PHP, Rust, Java, C# and Elixir. Hookgres’s tests check its signatures against the JavaScript one.
webhook-id: msg_… -webhook-timestamp: … -webhook-signature: v1,… - -…+
webhook-id: msg_2KWPBgLlAfxdpx2AI54pPJ85f4W +webhook-timestamp: 1794554750 +webhook-signature: v1,K5oZfzN95Z9UVu1EsfQmfVNQhnkZ2pj9o9NDN/H/pI4= + +{"type":"invoice.paid","data":{"invoiceId":"in_123","amount":4200}}
import { Webhook } from "standardwebhooks"; + +const wh = new Webhook(secret); // "whsec_..." +const event = wh.verify(rawBody, headers); +// throws if the signature fails or the timestamp is too old+
from standardwebhooks.webhooks import Webhook + +wh = Webhook(secret) # "whsec_..." +event = wh.verify(raw_body, headers) +# raises if the signature fails or the timestamp is too old+
import standardwebhooks "github.com/standard-webhooks/standard-webhooks/libraries/go" + +wh, err := standardwebhooks.NewWebhook(secret) +err = wh.Verify(body, r.Header) +// err is set if the signature fails or the timestamp is too old+
require "standardwebhooks" + +wh = StandardWebhooks::Webhook.new(secret) +event = wh.verify(raw_body, headers) +# raises if the signature fails or the timestamp is too old+
$wh = new \StandardWebhooks\Webhook($secret); + +$wh->verify($body, $headers); +// throws if the signature fails or the timestamp is too old+
Demo secret whsec_…, generated for this page.
Delivery log
+hookgres.deliveries
Every attempt is a row you can query.
-Status, response body and timing for each request, stored next to your data. Build a customer-facing log, a support view or an alert with plain SQL.
+Status, response body and timing for each request, stored next to your data. A customer-facing log or a support view is one SQL query away.