Webhook Guide
Retry Policy & Best Practices
Webhook retry behavior, failure handling, and production best practices for reliable webhook integration.
How M2P handles failed webhook deliveries and production best practices for building a reliable webhook integration.
Retry Policy
If your endpoint does not return HTTP 200 within 10 seconds, M2P automatically retries with exponential backoff:
| Attempt | Delay After Previous | Total Elapsed |
|---|---|---|
| Initial delivery | — | 0s |
| 1st retry | 30 seconds | 30s |
| 2nd retry | 2 minutes | 2m 30s |
| 3rd retry | 10 minutes | 12m 30s |
| 4th retry | 1 hour | 1h 12m 30s |
| Final retry (5th) | 4 hours | 5h 12m 30s |
After 5 failed attempts, the event is marked as permanently failed and logged. Contact M2P support to replay failed events if needed.
Best Practices
| Practice | Why It Matters |
|---|---|
| Return 200 immediately, process asynchronously | Prevents timeouts — acknowledge receipt first, then process |
Store eventId and deduplicate | Events may be retried — use eventId to detect and skip duplicates |
| Verify signature before processing | Prevents webhook spoofing — see Signature Verification |
| Use a message queue (e.g., SQS, RabbitMQ, Redis) | Decouples receipt from processing — ensures no events are lost |
| Log all events | Enables debugging, auditing, and event replay |
| Monitor consecutive failures | Alert your team when multiple deliveries fail in a row |
| Handle unknown event types gracefully | Future-proof your handler — return 200 for unrecognized events |
Recommended Architecture
- Webhook endpoint — Receives the HTTP POST, verifies the signature, and immediately returns 200
- Message queue — Durably stores the event for async processing
- Worker process — Consumes events from the queue, applies business logic, and updates your database