A 200 response is not the same as completed work
If processing can take time, accept the event, persist enough context and move the business operation to a queue. The sender should not wait for a slow ERP or fulfillment request.
Idempotency protects business operations
Use a stable event or business identifier. Before creating a downstream resource, check whether that operation was already completed. This is more important than trying to guarantee that a webhook arrives exactly once.
Retries need limits and visibility
Blind infinite retries create noise and can hammer an unhealthy API. Use backoff, a maximum policy and a failed state that operators can inspect and replay after fixing the cause.
Keep enough evidence to diagnose failure
Logs should connect the WooCommerce order, event identifier, target system and result. Avoid storing secrets, but keep enough metadata to answer what happened without reproducing production traffic.
- Persist an event identifier
- Make side effects idempotent
- Acknowledge quickly when processing is asynchronous
- Retry with backoff
- Expose a failed/replayable state
- Correlate logs across systems