Webhook Retry and Dead-Letter Handling

[Baskarayelu]

Description:

If anchor (or other) webhooks are processed asynchronously, implement retry and dead-letter handling so no event is lost.

Requirements

• On webhook receive: persist raw payload to a table or queue with status (pending/processed/failed)
• Process in background; on failure retry up to N times with backoff
• After max retries move to “dead letter”; optional GET /api/admin/webhooks/dlq (protected, admin only) to list and replay
• Document retry policy and DLQ

Acceptance Criteria

• Retry and DLQ implemented
• Admin endpoint optional
• Documented

[drips-wave]

This issue has been added to the Stellar Wave Program and is worth 200 Points.

🧑‍💻 Interested in contributing? Apply to work on this issue on Drips Wave, earn points, and receive rewards.

Warning

Only applications submitted via the apply link above will be considered. Please do not apply by commenting on the issue or opening a PR directly.

🤠 Repo maintainers: You can manage this issue's Points and Complexity on your Maintainer Dashboard here. Please keep an eye on applications and respond quickly 💙

ℹ️ Learn more about Drips Wave

[codewithzubair07]

@codewithzubair07 has applied to work on this issue as part of the Stellar Wave Program's 2nd wave.

Hi 👋

I’d like to take this webhook reliability issue.

I have experience implementing resilient webhook pipelines with persistence layers, retry mechanisms (exponential backoff), and dead-letter queue (DLQ) handling. I’ve worked on background job processing, failure recovery strategies, and secure admin endpoints for replaying failed events.

For this task, I will:

• Persist incoming webhook payloads with status tracking (pending/processed/failed)
• Implement background processing with retry (N attempts + backoff strategy)
• Move failed events to a dead-letter state after max retries
• Optionally add a protected admin endpoint to list and replay DLQ events
• Document retry policy and DLQ behavior clearly

GitHub: https://github.com/your-username
ETA: 2–3 days after assignment

Looking forward to contributing 🚀

ℹ️ Repo Maintainers: To accept this application, review their application or assign @codewithzubair07 to this issue.

[drips-wave]

Congratulations, @codewithzubair07! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on February 26, 2026.

🧑‍💻 @codewithzubair07: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are issued when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊