Delivery lifecycle
Every time a subscribed event fires, DeepSmith creates a delivery for each active webhook that matches the event type. Each delivery follows this lifecycle:Delivery statuses
Retry policy
Failed deliveries are retried automatically with exponential backoff:A delivery is considered failed when your endpoint returns a non-2xx HTTP status code, the connection times out (15 second limit), or a connection error occurs.
failed and the webhook’s consecutive_failures counter is incremented.
Auto-disable
When a webhook accumulates 10 consecutive failures, it is automatically disabled to protect your endpoint from unnecessary traffic. When a webhook is auto-disabled:- Its status changes to
DISABLED - No further deliveries are sent
- You can re-enable it from Settings > Webhooks, which resets the failure counter
Viewing delivery history
Open a webhook from Settings > Webhooks and navigate to the Deliveries tab. You can filter deliveries by event type and status (delivered, failed, recovered).
Sample delivery log
Delivery fields
Retrying a failed delivery
From the delivery log, click Retry on any failed delivery. This re-queues the delivery with the original event type and payload. The new attempt appears as a separate entry in the delivery log.Only failed deliveries can be retried. The retry button is not available for successful deliveries.
Performance stats
The webhook detail page shows performance charts for Event deliveries (total vs. failed) and Response time (min, avg, max). You can switch between three time periods:Sample stats response
Best practices
Respond quickly
Respond quickly
Return a
200 status code as fast as possible. Process the webhook payload asynchronously (e.g., queue a background job) rather than doing heavy work in the request handler. DeepSmith enforces a 15-second timeout.Handle duplicates
Handle duplicates
Use the
X-Webhook-Delivery header to deduplicate deliveries. Your endpoint may receive the same event more than once due to retries.Monitor your error rate
Monitor your error rate
Check the
error_rate on your webhooks and the performance charts regularly. A rising error rate indicates your endpoint may have issues.Use a queue
Use a queue
Don’t process webhooks synchronously. Push them onto a queue (SQS, Redis, RabbitMQ) and process them asynchronously. This keeps your endpoint responsive and prevents timeouts.
Log everything
Log everything
Log incoming webhook payloads and your processing results. DeepSmith’s delivery history shows what was sent, but your logs capture how your application handled it.