Skip to content

Why Centrali?

Centrali is the backend layer for webhook-backed applications. It is built for teams that need to accept third-party events, persist them as durable records, run code and automations from those records, expose synchronous APIs when needed, and send outcomes back out through realtime or outbound webhooks.

If your product lives on top of external events and needs one place to ingest, store, query, react, and fan data back out, that is the job Centrali is designed to do.

The Core Model

Receive -> Store -> React -> Send
  1. Receive: Accept inbound HTTP traffic asynchronously through webhook-style HTTP triggers. Use endpoints when you need synchronous request/response behavior.
  2. Store: Persist incoming payloads and business data as records you can inspect, query, search, and reuse later.
  3. React: Run functions, record-driven triggers, scheduled jobs, and automations against that stored data.
  4. Send: Fan results out through outbound webhooks, notifications, or realtime streams.

Where Centrali Fits Best

  • Products that are driven by third-party events, partner integrations, or internal system-to-system traffic
  • Teams that need a durable event history instead of depending on a provider's short retention window
  • Applications that need both synchronous APIs and asynchronous workflows from the same backend
  • SDK-first products built with Next.js, React, Vue, or a custom frontend
  • Multi-tenant or multi-workspace products that need isolation at the platform layer
  • Systems that need searchable records, stored payloads, and downstream automation without stitching together multiple services first

What Makes Centrali Different

Durable event storage, not just request handling

Accepted webhook payloads can become records. That gives you a long-lived system of record for replay, reconciliation, support tooling, audits, and follow-up automation.

One backend across async and sync entry points

HTTP triggers, endpoints, record events, schedules, and automations all reuse the same data model and function runtime. You do not need one stack for integrations and another for your application backend.

SDK-first application architecture

Centrali is designed to sit behind your application, not replace it. Pair it with Next.js, React, Vue, or a custom UI stack through the SDK or API. Pages exists, but it is not the main docs path.

Flexible auth without forcing a migration

Use service accounts for backend-to-backend work, or bring your own user tokens from Clerk, Auth0, Okta, or another OIDC provider when Centrali sits behind your existing auth layer.

When to Choose Centrali

Choose Centrali if you need:

  • Webhook ingestion with signature validation and asynchronous processing
  • Durable records you can query, search, enrich, and react to later
  • Functions and automations on top of the same stored data
  • Synchronous custom APIs and asynchronous event workflows from one backend
  • Workspace isolation, service accounts, and BYOT auth in the same platform

Consider another stack first if:

  • Your main requirement is a relational database with raw SQL as the primary developer surface
  • Your app is mobile-first and depends heavily on offline sync
  • You want a self-hosted or open-source-first platform as the main requirement
  • Your main programming model is reactive client queries rather than event ingestion and backend workflows