Tonder’s webhook system is designed for reliability. If your endpoint is temporarily unavailable, we will automatically retry the delivery.

How Webhook Delivery Works

The webhook delivery follows these sequential steps from event creation to final resolution:
1

Event Triggered

A transaction status change or event occurs
2

Immediate Delivery

Tonder sends a POST request to your webhook endpoint
3

Response Evaluation

Your endpoint’s response determines next steps
4

Success or Retry

Based on the response, the event is marked complete or scheduled for retry

Retry Policy and Configuration

When a webhook delivery fails, Tonder automatically retries according to a predefined policy:
SettingValueDescription
Max Retry Attempts3We will try to deliver a webhook up to 3 times
Processing Timeout30 seconds per attemptYour endpoint must respond within 30 seconds
Retry Interval60 secondsWe wait 60 seconds before retrying a failed attempt
Total Retry Window~3 minutesThe maximum time spent retrying a single event

Success and Failure Criteria

A delivery is considered successful if your endpoint responds with a 2xx HTTP status code within 30 seconds. Any other response is considered a failure, and a retry will be scheduled.

Common Failure Scenarios

Based on the original webhook system, these are the failure scenarios that trigger retries:
  • 4xx errors (400, 401, 404, etc.) - Client errors indicating request problems.
  • 5xx errors (500, 502, 503, etc.) - Server errors indicating endpoint issues.
  • Timeouts when no response is received after 30 seconds.
After 3 failed attempts, the message is moved to a Dead Letter Queue (DLQ) for manual inspection.

Dead Letter Queue (DLQ)

The Dead Letter Queue stores failed webhook events that couldn’t be delivered after all retry attempts:
  • Failed events are stored for manual inspection and potential reprocessing.
  • Access is available through the Tonder dashboard or support team.
  • Events can be manually retried after fixing endpoint issues.

Implementation Considerations

Key practices mentioned in the original webhook documentation:
  • Acknowledge receipt immediately with a 200 OK status to prevent timeouts.
  • Use the event_id to deduplicate events and prevent processing the same event twice.
  • Keep detailed logs of all incoming webhook events for debugging purposes.
  • Ensure that malformed payloads or processing errors don’t crash your system.

Next Steps

After understanding delivery and retry logic: