The backend for webhooks in and out

Ingest third-party webhooks. Store them as data. Send your own.

Ingest webhooks from Stripe, GitHub, and your partners. Emit your own signed webhooks and workflows from the same backend.

IngestStoreSend

How it works

Event sources in. Powered outcomes out. One SDK in the middle.

Centrali sits between event sources (Stripe, GitHub, Shopify, Clerk, custom webhooks) and powered outcomes (your app, internal ops, customer workflows, outbound webhooks, notifications). The four-step spine — Ingest, Store, Query, Send / automate — runs through the middle.

Webhook ingestion

Verify and persist incoming webhooks from any provider.

Store every Stripe event as a record

// Compute function wired to an HTTP trigger.
// Signature verification is configured on the trigger
// in the console, so invalid requests never reach this code.
async function run() {
  const event = executionParams.payload;

  await api.createRecord('stripe-events', {
    eventId: event.id,
    eventType: event.type,
    raw: event,
  });
}

Every third-party system ships its own signature format. Centrali's HTTP trigger validates them all. Verify once, store as a record, process on your schedule.

Pluggable HMAC validators for Stripe, Svix, and GitHub — configurable algorithm, encoding, and timestamp tolerance.
Verification happens before your function runs. Invalid signatures never reach your code.
Accept-and-store pattern: persist the raw payload, process asynchronously via workflows.

Supabase edge functions can handle this flow, but signature verification is still code you write yourself.

Read the docs

Outbound webhooks

Send signed, retried, observable webhooks from the same SDK.

HMAC-SHA256 signing with rotatable signing secrets.
Exponential-backoff retries — 30s, 2m, 10m, 30m, max 5 attempts.
Per-delivery logs with full request, response, status code, and latency.
Replay failed deliveries or cancel pending retries from SDK, REST, or console.
Subscribe only to the events or collections you care about.

Emit your own webhooks — order updates, job completions, audit events — without building the infrastructure. Every delivery signed, retried on failure, logged end-to-end, replayable with one click. Same SDK that ingests them.

Subscribe a customer endpoint — one SDK call

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

// Signing, retries, delivery logs, and replay are all handled.
const sub = await centrali.webhookSubscriptions.create({
  name: 'customer-acme-orders',
  url: 'https://customer-acme.example.com/webhooks',
  events: [RecordEvents.CREATED, RecordEvents.UPDATED],
  recordSlugs: ['orders'],
});

// `sub.data.secret` is returned once on create —
// hand it to your customer so they can verify deliveries.
console.log('Signing secret:', sub.data.secret);

Built-in signing, retries, replay, and delivery logs from the same SDK. Teams that need customer-facing webhook portals or highly configurable delivery controls can pair Centrali with Svix.

Read the docs

Automations

Chain events into multi-step workflows with decisions, delays, and per-run observability.

Workflow diagram: an incoming Stripe invoice.payment_succeeded event flows into a decision step that branches on amount. Low-value branch writes records (payments, customers, audit); high-value branch fires a customer webhook and notifies Slack. Each node shows status, duration, response, logs. — Webhook in. Actions out. One workflow.

When one event needs more than one step, turn it into a workflow. Decision branches, delay steps, per-run observability. Debug without guessing.

Multi-step workflows with decision branches (10+ comparison operators) and delay steps.
Flexible triggers — data events, HTTP webhooks with signature validation, cron schedules, on-demand.
Step-level input/output, activity logs, and execution traces per run.
Functions run JavaScript with the Centrali SDK built in — records, crypto, templating, file storage.

Ahead of Supabase and Firebase on native workflow orchestration. Teams with deeply durable, long-running workloads may still want Inngest or Trigger.dev.

Read the docs

Search

Full-text search across your records — including the events you've ingested.

Find every failed charge last week. Match each to its order.

Two queries, one backend. No search cluster, no ETL.

Full-text search at the collection level — across your app data and your ingested event records. Configure per collection, no separate search service to operate.

Collection-scoped FTS, configured per collection.
Query-time filters and relevance scoring.
Same search works across ingested event records and your own application records.

Firebase has no native Firestore full-text search and usually needs a second system. Centrali keeps search inside the same backend surface.

Read the docs

External identity

Bring your own auth — Clerk, Auth0, Keycloak, Okta.

Works withClerkAuth0KeycloakOktaany OIDC provider

Centrali doesn't ship an auth product for you to outgrow. Bring your own IdP. Identity flows through to functions, automations, and per-record access rules.

First-class OIDC support, tested with Clerk, Auth0, Keycloak, and Okta.
IdP claims map to Centrali users and roles.
Identity propagates to functions, automations, and data access.

Unlike bundled-auth platforms, Centrali is designed to work with the identity provider you already use.

Read the docs

Where the event data lives

Typed collections, encrypted secrets, direct-URL file storage.

Every ingested webhook becomes a record. Every record is a typed, queryable, first-class object — the same shape your app data uses. This is where the events live.

Schema-enforced collections with declarative relationships.
Secret fields encrypted at rest (AES-256-GCM), masked in API responses.
Direct-URL file storage with on-the-fly image transforms.
SDK and REST API parity — every primitive is scriptable.

Read the docs

Stop stitching webhook tools, storage, and backend logic together.

Build on the backend for webhooks in and out.