Webhook

Unlike a synchronous API call that blocks the client until a response is received, a webhook is a fire-and-forget mechanism. The provider dispatches the notification and immediately resumes its work without waiting for the consumer to finish processing.

• Decoupling: The sender does not need to know the internal logic of the receiver.
• Non-Blocking: Prevents slow downstream consumers from degrading the performance of the source system.
• Retry Logic: Robust providers implement exponential backoff if the receiving endpoint returns a non-2xx status code.

Because a webhook endpoint is a publicly accessible URL, it is vulnerable to malicious actors. HMAC (Hash-Based Message Authentication Code) signatures are the standard defense mechanism.

• Signing Secret: A shared private key used to hash the payload.
• Header Inspection: The signature is sent in a custom header (e.g., X-Webhook-Signature).
• Replay Attack Prevention: Timestamps are often included in the signed payload to reject stale, intercepted requests.

To prevent abuse and verify endpoint ownership, many platforms implement a one-time verification challenge during the subscription setup.

• Challenge Code: The provider sends a unique token to the target URL.
• Echo Response: The consumer must respond with the exact token or a computed hash to prove control.
• Auto-Disable: If verification fails or the endpoint remains unhealthy, the subscription is automatically paused to save resources.

Network partitions and server errors are inevitable. A production-grade webhook system requires a sophisticated retry strategy to guarantee eventual delivery.

• Exponential Backoff: Retries occur with increasing delays (e.g., 1s, 10s, 100s).
• Dead Letter Queues: Events that fail after maximum retries are stored for manual inspection rather than being silently dropped.
• Manual Replay: Administrative interfaces allow developers to resend historical events to fix downstream data corruption.

To avoid overwhelming the consumer, advanced webhook gateways allow subscribers to specify exactly which events they care about and how frequently they receive them.

• Topic Filtering: Subscribe only to order.shipped instead of all order.* events.
• Field Selection: Request a lightweight payload containing only the resource ID, forcing the consumer to fetch full details via API if needed.
• Rate Limiting: Cap the maximum number of deliveries per second to protect fragile legacy endpoints.

A software design paradigm where system behavior is triggered by the occurrence of events—such as content publication or user registration—rather than continuous polling. Webhooks are the primary HTTP-based transport mechanism in this model. Key characteristics include:

• Producers emit events without knowing the consumers
• Consumers subscribe to specific event types
• Decouples services for independent scaling and deployment
• Contrasts with polling, which wastes compute cycles checking for changes that haven't occurred

The structured data body delivered in the HTTP POST request when a webhook fires. In headless CMS platforms, the payload typically contains:

• Event type (e.g., entry.publish, asset.delete)
• Resource identifier and version metadata
• Changed fields or a full snapshot of the content object
• Timestamp and environment context Payloads are usually serialized as JSON and should be validated against a schema by the receiving endpoint to prevent injection attacks.

The strategy a webhook sender employs when the destination endpoint is unreachable or returns a non-2xx status code. Robust implementations use exponential backoff:

• First retry after 1 minute
• Second retry after 5 minutes
• Third retry after 25 minutes
• Subsequent retries at increasing intervals up to a maximum cutoff (e.g., 24 hours) This prevents overwhelming a recovering downstream service while ensuring eventual delivery.

Both enable server-to-client communication, but they serve fundamentally different patterns:

• Webhooks: Fire-and-forget HTTP callbacks for discrete events; the connection closes after delivery
• SSE: A persistent, long-lived HTTP connection where the server streams multiple events to a subscribed client
• Webhooks are ideal for service-to-service integration; SSE suits real-time browser updates
• Webhooks scale horizontally; SSE requires maintaining open connections per client

The property that ensures processing the same webhook event multiple times produces the same result as processing it once. This is critical because network failures can cause duplicate deliveries. Implementation strategies:

• Include a unique idempotency key (e.g., X-Webhook-Id) in each delivery
• The receiver stores processed keys and skips duplicates
• Use database transactions to atomically check the key and apply the mutation
• Essential for financial or inventory operations where double-processing is catastrophic