Skip to content
HookWatch beta
FeaturesUse casesPricingQuickstartSecurityCompare
Resources
Resources overviewSandbox (live receiver)Developer toolsGuidesIntegrationsComparisonsChangelogDocumentationMCP server
Sign in Start beta
Integration

Consuming Supabase Database Webhooks: Real-Time Event Ingestion and Reliability

How to configure, secure, and debug Supabase Database Webhooks (INSERT, UPDATE, DELETE), verify authorization headers, and recover failed webhook executions.

Published 2 min read
On this page

Supabase allows configuring Database Webhooks triggered automatically by PostgreSQL row-level changes (INSERT, UPDATE, DELETE) via pg_net and Supabase Edge Functions.

Whether you are syncing database mutations to search indexes (Algolia, Typesense), triggering asynchronous background jobs, or notifying external partner services, reliable delivery of Supabase Database Webhooks is essential.

How Supabase Database Webhooks work

When a row in a specified table changes, PostgreSQL triggers an HTTP request via the pg_net extension:

  • type: Change type (INSERT, UPDATE, DELETE).
  • table: Table name that triggered the event.
  • schema: Database schema (typically public).
  • record: The new row data (present on INSERT and UPDATE).
  • old_record: The previous row data (present on UPDATE and DELETE).

Securing Supabase webhook endpoints

Supabase webhooks can be configured with custom HTTP request headers for authentication. The standard practice is to pass a shared secret token in an Authorization header:

Authorization: Bearer sb_sec_YOUR_WEBHOOK_SECRET

Your receiver must validate this header before executing database queries or business logic.

Common failure modes with Database Webhooks

  1. pg_net timeout on bulk writes: Large batch updates (e.g. UPDATE orders SET status = 'processed' WHERE ...) can trigger hundreds of simultaneous webhook HTTP requests. If your server is not scaled for concurrency, requests will queue up and time out.
  2. Infinite update loops: If your webhook handler updates the same Supabase table that triggered the webhook, it can cause an infinite cascade of database events.
  3. Out-of-order execution: Two rapid updates to the same row can arrive at your receiver out of order due to network latency. Always check row timestamps or version columns.

Capturing and Replaying with HookWatch

HookWatch acts as a resilient buffer and inspector in front of your internal workers:

  • Catch every database event payload from Supabase with low latency.
  • Protect your primary backend from spikes with smooth queuing.
  • Group repeated endpoint errors into incidents and replay failed deliveries after schema migrations.

Related resources

Idempotency Webhook Idempotency: Preventing Duplicate Payments and Actions Duplicate webhook deliveries are normal, not a bug. How to make handlers idempotent with event IDs, a processed-events table, database uniqueness, correct transaction boundaries, and production Go — so replays and retries never charge a customer twice. 11 min read Reliability Webhook Retry Best Practices: Backoff, Jitter and Attempt Limits How to retry failed webhook deliveries without causing retry storms: fixed vs exponential backoff, jitter, attempt limits, which status codes are retryable, Retry-After, and dead-letter handling. 11 min read Debugging How to Debug Failed Webhooks: A Step-by-Step Guide A systematic walkthrough for diagnosing failed webhook deliveries: connectivity, status codes, timeouts, signatures, handler exceptions, and a production debugging checklist. 9 min read
Get started

See what happened to every webhook.

HookWatch keeps the request, the response, and every attempt for each delivery — so the debugging, retry, and replay steps in this article are a matter of reading, not reconstructing.

Start using HookWatch Read the documentation