| 1 |
--- |
| 2 |
module: webhook |
| 3 |
--- |
| 4 |
|
| 5 |
# webhook |
| 6 |
|
| 7 |
## Responsibility |
| 8 |
|
| 9 |
Owns the full outbound webhook lifecycle: CRUD of webhook configs in a single `wp_options` row, mapping WordPress/WooCommerce actions to five named events, building the JSON payload, and delivering it HMAC-signed and asynchronously via Action Scheduler, with retries. |
| 10 |
|
| 11 |
Ownership stops at the wire — it does not own the admin UI, nor the REST/AJAX endpoints that call `add_webhook` and `send_test`, nor Action Scheduler itself. |
| 12 |
|
| 13 |
## Why it is this way |
| 14 |
|
| 15 |
Delivery is deliberately asynchronous and the payload is built at *dispatch* time rather than at delivery time, so a retry cannot observe a mutated order. The cost is that a retry hours later resends stale state, and that the payload — including customer PII — is persisted in the Action Scheduler args table for the life of the action log. |
| 16 |
|
| 17 |
The 60-second dedup transient exists because two WooCommerce order statuses (`processing` and `completed`) both map to `order_completed`. It narrows the window rather than closing it, so receivers must be idempotent on `order_id` regardless. |
| 18 |
|
