TL;DR — One API call subscribes a customer endpoint. Centrali signs each delivery with HMAC-SHA256, retries 5 times over ~40 minutes on failure, logs every attempt, and exposes a one-line replay endpoint. No queue. No retry logic. No Svix. The whole subscribe call is right below — scroll to it if you just want the shape.

Your customers want webhooks. You know the checklist:

A queue so user requests don't block on HTTPS calls to third-party servers
HMAC signing so customers can verify the request came from you
Retry with exponential backoff, jitter, a max attempt count
A circuit breaker so flaky endpoints don't cost you compute
A delivery log with replay for the "we never got that event" support ticket
A subscription model with rotatable secrets, event filters, active/inactive state

It's two weeks of work, plus ongoing maintenance. This post shows how to skip all of it.

The whole thing, in one SDK call

typescript

import { CentraliSDK, RecordEvents } from '@centrali-io/centrali-sdk';

const sub = await centrali.webhookSubscriptions.create({
  name: 'customer-acme-order-events',
  url: 'https://customer-acme.example.com/webhooks',
  events: [RecordEvents.CREATED, RecordEvents.UPDATED],
  recordSlugs: ['orders'],
});

// `secret` is returned on create only — copy it now, reads omit it.
console.log('Signing secret:', sub.data.secret!);

That's the whole setup. HMAC signing, retry, circuit breaker, delivery log, replay — all behind that one call. The rest of this post explains what just got handled for you, and shows how to wire up the customer side.

What you'd build yourself (and won't have to)

Before the tutorial, the honest version of what ships with a production-ready webhook system:

An outbound queue. You can't block the user's API request on an HTTPS call to a customer server. Something has to pull from a queue (Redis, SQS, BullMQ) and dispatch asynchronously.
HMAC signing. Sign the raw body with the subscription's secret, attach as a header. Secrets must be rotatable and scoped per subscription.
Retry with backoff. When a delivery fails (5xx or timeout), retry — but not immediately, and not forever. Exponential backoff is the baseline. Most teams get this subtly wrong: no jitter, too many attempts, too aggressive early.
Circuit breaker. When a customer's endpoint has been failing for minutes, stop attempting. Resume when it's healthy. Otherwise you waste compute on doomed requests and compound the outage.
Delivery log. Every attempt: HTTP status, response body, error, timestamp. This is the contract with support. When a customer asks "did you send it?", the log is the only answer that matters.
Manual replay. Customer deploys a fix, wants to catch up on the last hour. They need a replay endpoint. It shouldn't duplicate into your retry queue.
A subscription model. Customers create subscriptions, scoped to events and record types. Activate/deactivate. Rotate the secret without losing history.

Each item is a day of work. Together they're a sprint. Maintained well, they're an ongoing tax on your platform team.

What Centrali gives you

One line each, mapped to the list above:

Outbound queue: built in, no worker to deploy. Dispatch happens on record changes automatically.
HMAC signing: SHA-256 over the raw body, base64-encoded, header is X-Signature. Secret is whsec_…, auto-generated per subscription, rotatable.
Retry with backoff: 5 attempts over ~40 minutes — delays of 30s, 2m, 10m, 30m between attempts.
Circuit breaker: per-URL, opens when an endpoint is consistently failing, resets after a cool-down. Flaky endpoints stop costing you compute.
Delivery log: every attempt stored — HTTP status, error, payload, response body — visible in the console and queryable via API.
Manual replay: one endpoint — POST /webhook-subscriptions/deliveries/{id}/retry. New delivery is linked to the original via replayedFrom.
Subscription model: collection-scoped (via recordSlugs), event-type-filtered (record_created, record_updated, record_deleted), active/inactive, rotatable secret.

Tutorial: ship an outbound webhook in 5 minutes

The demo: a SaaS that tracks orders. When an order is created or updated, subscribed customers get a webhook.

Step 1: Create a collection

If you don't have one already, create an orders collection in the Centrali console. Any collection works — Centrali emits record events for every collection in the workspace.

Orders records table with pending, paid, and refunded orders

Step 2: Subscribe a customer endpoint

You already saw the subscribe call at the top of the post. The response wraps the subscription under sub.data — the two fields that matter:

sub.data.id — subscription ID for updates and delivery queries
sub.data.secret — signing secret, returned once on create. Save it and hand it to your customer so they can verify incoming requests. If lost, rotate in the console: old-secret deliveries stay in the log, new deliveries use the new secret.

The console view shows the subscription with URL, event filters, a masked rotatable secret, signature header, and algorithm:

Subscription detail view showing URL, events, record filter, signing secret, and signature header

Prefer raw HTTP? Same shape over REST — POST /data/workspace/{your-workspace}/api/v1/webhook-subscriptions with a bearer token and a body matching the SDK call. Translating fetch or any HTTP client is one-to-one.

Step 3: Trigger an event

Any record change in the orders collection now fans out to subscribed endpoints. Create an order:

typescript

await centrali.createRecord('orders', {
  orderNumber: 'ORD-1045',
  customerEmail: 'pia@terradome.studio',
  total: 210,
  currency: 'USD',
  status: 'pending',
  itemCount: 3,
});

Centrali dispatches a POST to the subscribed URL within seconds. The request body looks like this:

json

{
  "event": "record_created",
  "workspaceSlug": "demo",
  "recordSlug": "orders",
  "recordId": "7d5a87d5-b10c-48bb-85d8-c42dbdaab417",
  "data": {
    "orderNumber": "ORD-1045",
    "customerEmail": "pia@terradome.studio",
    "total": 210,
    "currency": "USD",
    "status": "pending",
    "itemCount": 3,
    "placedAt": "2026-04-22T04:59:00Z"
  },
  "timestamp": "2026-04-22T04:59:02Z"
}

And the headers include the HMAC signature:

text

X-Signature: xXyHjYrTLS0bKh9qypUv8U5fj5UwBpIn2u0loyEoSQg=
Content-Type: application/json
User-Agent: Centrali-Webhooks/1.0

webhook.site showing the request payload and X-Signature header

Step 4: Verify the signature on the customer side

The signature is HMAC-SHA256(signingSecret, rawBody), base64-encoded. The critical word is raw: compute it over the exact bytes you received, before any JSON parsing or middleware touches them.

Here's an Express.js handler that does it right:

javascript

import express from 'express';
import crypto from 'crypto';

const app = express();
const WEBHOOK_SECRET = process.env.CENTRALI_WEBHOOK_SECRET;

// Use raw body middleware for the webhook route only
app.post(
  '/webhooks/centrali',
  express.raw({ type: 'application/json' }),
  (req, res) => {
    const signature = req.get('X-Signature');
    if (!signature) return res.status(400).send('missing signature');

    const expected = crypto
      .createHmac('sha256', WEBHOOK_SECRET)
      .update(req.body) // req.body is a Buffer of the raw bytes
      .digest('base64');

    const valid = crypto.timingSafeEqual(
      Buffer.from(signature),
      Buffer.from(expected)
    );

    if (!valid) return res.status(401).send('invalid signature');

    const event = JSON.parse(req.body.toString('utf8'));
    console.log('got event:', event.event, event.recordId);

    // Do work, then 2xx to acknowledge
    res.status(200).send('ok');
  }
);

The two gotchas that trip up every first implementation:

Parse after verification. If you let express.json() touch the request first, the raw bytes are gone and the signature won't match. Use express.raw() for this route only.
Constant-time comparison. === leaks timing information. Use crypto.timingSafeEqual or your language's equivalent.

Normally you'd be writing the signing code too — on your server. Here your server doesn't ship webhook code at all. The only HMAC work is on the customer's end, which is where it belongs.

What happens when the customer's endpoint is down

The honest failure mode is what sells the feature. Create a second subscription pointed at a deliberately broken endpoint:

typescript

await centrali.webhookSubscriptions.create({
  name: 'customer-globex-order-events',
  url: 'https://httpbin.org/status/500',
  events: [RecordEvents.CREATED, RecordEvents.UPDATED],
  recordSlugs: ['orders'],
});

Trigger any order event and watch the delivery log. The first attempt fails with HTTP 500. The next four attempts happen at +30s, +2m, +10m, +30m. The log stays visible the whole time, with live nextAttemptAt and attemptCount values:

Delivery log during retry — record_created and record_updated retrying at attempt 4

After the fifth attempt, the delivery's status flips to failed and the error is preserved:

Delivery log with failed deliveries after retry exhaustion

No retry code in your app. No job queue. No alerts you wired up and forgot about. Just a log you point support at when someone asks "did it send?".

Replay a failed delivery once the endpoint is healthy

The customer fixes their endpoint. They want the missed events. Replay any failed delivery by ID:

typescript

await centrali.webhookSubscriptions.deliveries.retry(deliveryId);

A new delivery is created, pointed at the current subscription URL. The new delivery's detail view shows the original delivery ID under replayedFrom — you always know where a replay came from:

Delivery detail showing Status Success, HTTP 200, attempts 1, Replayed from: 5a9b39e2-b695-44ba-aaae-be96bd3c4af8

If replay was the entire story, you'd still need a queue. But combined with automatic retry plus the delivery log, the customer flow becomes:

Customer endpoint goes down.
Centrali tries for ~40 minutes, then gives up (logged).
Customer fixes their endpoint.
Customer (or you, from their support request) hits the replay endpoint once.
Back to normal — no lost events.

What's in the subscription model

If you've used Svix or Hookdeck, this shape will feel familiar:

Field	Purpose
`name`	Display name — usually the customer's name + event scope
`url`	HTTPS endpoint that receives deliveries
`events`	Event types to subscribe to — `record_created`, `record_updated`, `record_deleted`
`recordSlugs`	Collection filter — deliver only for these record slugs
`status`	`active` or `inactive` — pause without deleting
`signingSecret`	Shared secret for HMAC signing (auto-generated, rotatable)
`signatureHeader`	Header name for the signature (default: `X-Signature`)
`algorithm`	HMAC algorithm (default: `sha256`)
`encoding`	Signature encoding (default: `base64`)

One subscription per customer-per-scope. Rotating the secret doesn't lose history — existing deliveries in the log remain readable, future deliveries use the new secret.

When you should still build it yourself

If webhooks are core to your product — you're Zapier, or Segment, or you're Svix — you need more than what's in a backend platform. Per-customer delivery portals, detailed per-endpoint SLAs, webhook-as-a-product pricing, platform-wide rate budgets. Those companies exist for a reason and the category is real.

If webhooks are a feature of your product — one of many things your API does, and your customers want them — you don't need dedicated webhook infrastructure. You need the seven things above, and you need them to work without turning into a team's full-time job.

That's what the platform you're already using gives you.

Follow along: Create a free workspace and subscribe your first endpoint in 5 minutes. No deployment required.

Add Webhooks to Your SaaS in 10 Minutes (Without Queues or Retries)

The whole thing, in one SDK call

What you'd build yourself (and won't have to)

What Centrali gives you

Tutorial: ship an outbound webhook in 5 minutes

Step 1: Create a collection

Step 2: Subscribe a customer endpoint

Step 3: Trigger an event

Step 4: Verify the signature on the customer side

What happens when the customer's endpoint is down

Replay a failed delivery once the endpoint is healthy

What's in the subscription model

When you should still build it yourself

Related reading