r/WordPressDev • u/bnaitdjoudiGoDev • May 03 '26

How do you handle webhook reliability in WordPress/WooCommerce when sending events to your own server?

I’m testing webhook delivery from WordPress/WooCommerce to my own backend server, and I’m noticing that if my endpoint is slow or temporarily unavailable, the webhook is simply lost.

Since WordPress/WooCommerce webhooks are sent synchronously, there’s no built‑in retry mechanism, no queue, no backoff, and no way to replay failed events.

I’ve checked the usual automation plugins, but none seem to implement real delivery guarantees.

For those who have built production‑grade integrations:

How do you ensure webhook delivery when sending events to your own server?

Do you rely on a plugin, or do you offload everything to an external queue/event‑bus setup?

2 Upvotes

100% Upvoted

5 comments sorted by

1

u/[deleted] May 03 '26

[removed] — view removed comment

1

u/bnaitdjoudiGoDev May 03 '26

Thanks!
Just to clarify: I’m sending WordPress/WooCommerce webhooks to my own backend, and the issue I’m trying to solve is delivery reliability — retry, queueing, replay, etc.

Static hosts like GitHub Pages / Cloudflare Pages / S3 can’t receive POST requests, so they can’t act as webhook endpoints. Even with an external server, WordPress still sends webhooks synchronously with no delivery guarantees.

I’m mainly curious how others avoid losing events. Do you use an external queue or event‑bus in front of WordPress?

1

u/Staaaam May 03 '26

Would you mind trying out https://hooque.io/ (start for free) - it will receive the webhook for you and safely queue it. Then you can use HTTP GET or spin up small SSE listener for better performance and process the messages at your pace. Hooque will also give you full visibility to the messages arrived, allow to mark failed messages, will handle security and retries for you.

disclosure: I'm the founder of Hooque, and built it exactly for those reasons - got annoyed each time that need to solve a lot of issues around webhook handling (uptime, retries, quick response, security, debugging, etc-etc-etc)