Database webhooks

A database webhook sends a signed POST to your URL after a write to a table — to update a search index, notify a service or start a workflow elsewhere. Set them up under Schema › Webhooks.

#Set one up

Test sends a sample event so you can check your endpoint.

#What is sent

{
  "type": "database.change",
  "project_id": "…",
  "table": "orders",
  "event": "INSERT",
  "timestamp": "2026-10-17T10:15:02.120Z",
  "event_id": "…",
  "data": { "row_count": 1 }
}

Like realtime change events, the payload says that rows changed and how many — not their contents. Fetch the rows you need with a server key. Headers: X-Sovaria-Delivery (unique per delivery) and X-Sovaria-Signature: sha256=<hex> (HMAC-SHA-256 of the raw body with your secret — check it as shown in Auth event hooks).

#Delivery, retries and dead letters

• Events are written to an outbox with the write and delivered by a background worker, so slow endpoints never slow your app's writes.
• A delivery succeeds on any 2xx. Otherwise it is retried after 10 seconds, 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours (7 attempts in all).
• After the last attempt it moves to the dead-letter queue on plans that include one — you can redrive it — or is marked failed and kept in the delivery log.
• Each webhook has a delivery log; delivered events can be replayed within your plan's replay window.
• Deliveries can repeat (a retry after a timeout): use event_id to ignore duplicates.
• Writes made over a direct Postgres connection don't go through the API and don't send webhooks.