Webhook Delivery and Retry Policy

To ensure high reliability and data integrity, Tackle employs an automated retry strategy for all outgoing webhooks. This guide outlines how our system handles delivery failures and how you should configure your endpoint to maintain a seamless integration..

---

Delivery Acknowledgement

To acknowledge receipt of an event, your endpoint must return a 2xx HTTP status code (e.g., 200 OK).

Response Requirements

• Method: POST

• Content-Type: application/json

• Timeout: Your endpoint must respond within 10 seconds.

[!TIP]

Performance Note: If your internal logic involves long-running processes (like complex database joins or external API calls), handle them asynchronously. Return a 200 OK immediately upon receiving the payload and move the heavy lifting to a background worker or message queue.

---

Retry Logic

If Tackle receives an error or no response from your server, we will automatically attempt to redeliver the event.

What Triggers a Retry?

• HTTP 429: Your server is rate-limiting requests.

• HTTP 5xx: Your server encountered an internal error.

Graduated Backoff Strategy

Tackle uses a graduated backoff strategy to avoid overwhelming your infrastructure during downtime. The delay between retries increases with each failed attempt, providing a recovery window of approximately 22 hours.

Max Retries: 12 attempts.

If the 12th attempt fails, the event is marked as Failed, and no further automated attempts will be made.

---

Implementation Best Practices

Routing by event_type

Each event_type maps to a specific schema within the payload object. While the top-level structure of Tackle webhooks is stable, always implement defensive parsing. If your code encounters an event_type it doesn't recognize, log the event for review but return a 200 OK to prevent unnecessary retries from the Tackle side.