Slow webhook processing can make a provider retry a request even while the first attempt is still working. A durable queue allows a prompt acknowledgement and controlled background processing.
IN THIS ARTICLE
Gather the details you will need
Confirm a reliable queue or event store and a supervised worker are available. Identify the provider’s response deadline and retry behavior.
01 Respond quickly while processing webhooks in a queue
Authenticate and validate the incoming event before accepting it. Reject malformed or unauthorised requests without placing trusted work in the queue.
Persist the event or job durably and record its identifier. Do not acknowledge success before the application has a reliable way to recover the accepted work.
Return the provider’s expected success response promptly after acceptance. Keep slow API calls, report generation and notifications out of the receiving request.
Process the job with duplicate protection, finite timeouts and a deliberate retry policy. Record completion separately from initial receipt.
Monitor queue age, failed jobs and provider delivery history. Provide an authorised way to inspect and replay eligible failed work.
02 Example: acknowledge durable work before processing it
For a harmless test notification, record a stable provider event ID and follow these distinct states.
| Stage | Required evidence |
|---|---|
| Received | The request has been authenticated and its expected type and account checked. |
| Accepted | The event or job is durably stored and can survive a worker restart; send the provider's documented success response. |
| Completed | The worker has performed the intended action once and stored its result. |
In staging, stop the worker after acceptance and restart it. The job should still be present and complete without a duplicate action. If durable storage fails, the endpoint must not falsely acknowledge reliable acceptance; return the failure behavior required by the provider and investigate storage or queue availability.
Confirm the expected result
Send a test event, confirm a quick acknowledgement and then verify the final business result. Stop and restart a worker in staging to confirm accepted work is not lost.
If the problem continues
A 200 response with no durable job can silently lose work. A queued job that never completes needs worker and failure-record investigation, not repeated webhook registration.
A common question
Does acknowledging an event mean the customer operation is finished?
Not in an asynchronous design. Track accepted and completed states separately so staff and integrations can tell whether the work is still pending.