A webhook sender usually needs a timely response. Performing a long catalog refresh, several API calls, and a notification delivery before responding can increase retries and tie up your server.
Moving work to the background helps only if the application has accepted it durably. Returning success and then keeping the event in a local variable can lose the task during a restart.
Define the acceptance point
Verify the request, validate the supported event shape, and store the event or queue item in a durable system. Return the response your provider's contract expects after that acceptance succeeds.
Keep the worker responsible for retryable processing. It should record whether work is pending, running, completed, or needs attention. A queue that holds only an event ID may need a reliable way to retrieve the associated payload later.
Avoid making the public response depend on an unrelated external notification. If that side effect fails, it should have its own recovery path rather than forcing the provider to repeat every earlier successful step.
Test the restart window
Accept a valid event, stop the application before the worker runs, and restart it. The work should still be present. Then stop the worker midway and confirm that unfinished work can be recovered according to your lease or retry design.
Also test a storage failure before acceptance. The endpoint should not claim successful handling when it could not keep the event.
A quick response is useful, but the real goal is a clear handover. The sender knows its message reached your application, and your application has enough durable information to finish the job after the connection is gone.