Overview

Anton is designed to deliver webhooks reliably. When a delivery attempt fails, Anton automatically retries with exponential backoff. This article covers the retry schedule, what counts as a failure, and how to monitor your webhook deliveries.

Successful Delivery

A webhook delivery is considered successful when your endpoint returns an HTTP 2xx status code (200, 201, 202, etc.) within 30 seconds. Anton does not inspect the response body -- only the status code matters.

What Counts as a Failure

A delivery attempt is marked as failed if:

Your endpoint returns a non-2xx status code (e.g., 400, 500)
The request times out after 30 seconds
A TCP connection cannot be established (endpoint is down or unreachable)
A TLS handshake fails (invalid or expired certificate)

Retry Schedule

When a delivery fails, Anton retries with exponential backoff according to this schedule:

Attempt	Delay After Previous Attempt
1 (initial)	Immediate
2	1 minute
3	5 minutes
4	30 minutes
5	2 hours
6	8 hours

After all 6 attempts are exhausted, the delivery is marked as permanently failed. The total retry window spans approximately 10.5 hours from the initial attempt.

Monitoring Deliveries

You can monitor webhook delivery status through both the merchant portal and the API.

Via the merchant portal: Navigate to Settings > Webhooks, select a webhook subscription, and view the delivery log. Each entry shows the event type, delivery status, HTTP status code, response time, and number of attempts.

Via the API:

curl https://api.antonpayments.dev/v1/webhooks/events/evt_abc123/deliveries \
  -H "Authorization: Bearer ak_test_..."

This returns each delivery attempt with timestamps, status codes, response times, and error details.

Manual Retry

If a delivery fails after all automatic retries, you can manually retry it from the merchant portal or via the API. Manual retries are useful when your endpoint was temporarily down and you want to recover missed events.

Best Practices for Reliable Delivery

Return 200 immediately -- Process webhook payloads asynchronously. Return a 200 response right away, then handle the event in a background job. This prevents timeouts.
Handle duplicates -- Use the event id field to deduplicate. In rare cases (network issues, retries), Anton may deliver the same event more than once. Your handler should be idempotent.
Monitor for failures -- Set up alerts when webhook deliveries fail. If your endpoint goes down, events queue up and you lose real-time visibility until the retries succeed.
Keep your endpoint available -- Ensure your webhook endpoint has high availability. If all retry attempts fail, you will need to manually recover the missed events.
Handle out-of-order delivery -- Events may arrive out of order. Use the created_at timestamp or the resource's actual status to determine the true state, rather than assuming events arrive sequentially.

Webhook Delivery and Retries