What is a Webhooks Delivery Schema?
Modern applications frequently require asynchronous, real-time event dissemination to external endpoints. The webhooks delivery schema provides the architectural framework necessary to register consumer URLs, subscribe to specific event types, queue outbound HTTP payloads, and log delivery outcomes with strict retry policies. Rather than forcing direct integrations, this pattern allows you to emit an event once and trust a dedicated processing system to dispatch it reliably.
Core Entities and Relational Integrity
At the center of a resilient webhook system are three fundamental database tables: subscriptions, delivery attempts, and event payloads. Below, we examine the responsibilities and constraints of each entity within the schema context.
- Webhook Subscriptions: Stores target URLs, active status, secret keys for cryptographic payload signing, and the specific event types (e.g.,
order.created,payment.failed) the consumer wishes to receive. - Event Payloads: A read-only audit log of events generated by the system. By separating payload storage from delivery tasks, you prevent database bloat and enable multi-cast routing where one event triggers multiple delivery attempts.
- Delivery Attempts: Tracks the execution state of each dispatch task. It logs the HTTP response status code, timestamps for scheduled retries, failure counts, and raw response snippets to facilitate debugging.
Ensuring Reliability with Exponential Backoff
Network instability and target server downtime are inevitable when delivering webhooks. To protect system resources, the delivery worker employs an exponential backoff retry strategy. The schema handles this by calculating the next scheduled run time using a simple formula: base_delay * (multiplier ^ attempt_count). The delivery record is updated after each failure, delaying subsequent attempts until the server has a chance to recover. If the attempt count exceeds a predefined threshold, the status transitions to failed, and the subscription may be automatically paused to prevent useless outbound traffic.
Verifying Webhook Authenticity
Security is paramount when pushing data to public endpoints. Each subscription contains a unique signing secret. When dispatching a payload, the delivery engine computes an HMAC signature using this secret and injects it into a custom header (e.g., X-Webhook-Signature). The receiving server uses the shared secret to recalculate the hash, verifying both the sender identity and payload integrity before processing the incoming event data.