Appearance
Retry Policy
The webhook delivery system automatically retries failed deliveries using exponential backoff.
Retry schedule
| Attempt | Delay after failure | Total elapsed |
|---|---|---|
| 1st (initial) | — | 0s |
| 2nd (retry 1) | 1 second | ~1s |
| 3rd (retry 2) | 5 seconds | ~6s |
| 4th (retry 3) | 30 seconds | ~36s |
After 4 attempts (1 initial + 3 retries), the delivery is marked as failed and no further retries are attempted.
What triggers a retry
| Scenario | Retried? |
|---|---|
| Network error / timeout | Yes |
| HTTP 429 (Too Many Requests) | Yes |
| HTTP 500–599 (Server Error) | Yes |
| HTTP 200–299 (Success) | No — delivery complete |
| HTTP 400–499 (Client Error, except 429) | No — delivery marked as failed |
Why no retry on 4xx?
Client errors (except rate limiting) indicate a problem with the receiving endpoint's configuration, not a transient issue. Retrying would not help. Fix the endpoint and the next collection update will trigger a fresh delivery.
Delivery status tracking
Each webhook endpoint has a delivery status that is updated after each delivery attempt:
| Status | Meaning |
|---|---|
success | Last delivery was successful |
failed | Last delivery failed after all retry attempts |
You can check delivery status via the Interplai platform UI.
Recommendations for your endpoint
- Respond quickly — return a 200 status as soon as possible, then process the data asynchronously
- Be idempotent — in rare cases, you may receive the same event twice. Use the
collectionIdandtimestampfields to deduplicate - Handle retries gracefully — if you receive multiple attempts for the same event, only process the latest one
- Return appropriate status codes:
200— successfully received429— you're temporarily overloaded (triggers retry)500— something went wrong on your end (triggers retry)400— the request is malformed (stops retries)
Monitoring
Check delivery status in the Interplai platform UI.