How WordPress webhooks trigger Magento cache purges
The OC Magento Bridge plugin sends signed HTTP POST requests to Magento whenever WordPress content changes. Magento uses these webhooks to purge only the affected cache entries, keeping cached content fresh without full cache flushes.
WordPress Hooks That Trigger Webhooks
| WordPress Hook | Event Sent | Object Type |
|---|---|---|
save_ | post_ or post_ | post or page |
delete_ | post_ | post or page |
wp_ | menu_ | nav_ |
edited_ | term_ | category or post_ |
delete_ | term_ | category or post_ |
Post revisions and autosaves do not trigger webhooks.
Webhook Payload
{
"event": "post_updated",
"object_type": "post",
"object_id": 42,
"slug": "my-post-slug",
"timestamp": 1700000000
} HMAC-SHA256 Signing
Each webhook is signed using the API key as the HMAC secret. The signature is sent in the X-OC-Bridge-Signature header:
X-OC-Bridge-Signature: abc123def456...On the Magento side, Controller/Webhook/CachePurge.php verifies the signature by computing the HMAC-SHA256 of the raw request body using the stored API key and comparing with hash_equals().
Magento Webhook Endpoint
The Magento webhook controller listens at:
POST /wordpress/webhook/cachepurgeEnter this URL in the WordPress plugin settings as the Magento Webhook URL.
Non-Blocking Delivery
Webhooks are sent using wp_remote_post() with blocking: false. This means the webhook is dispatched asynchronously - WordPress does not wait for Magento’s response before continuing. The webhook timeout is 10 seconds.
Cache Tag Mapping
After verifying the webhook signature, Magento maps the object_type to cache tags and purges them:
object_type | Cache Tags Purged |
|---|---|
post | WORDPRESS_, WORDPRESS_ |
page | WORDPRESS_, WORDPRESS_ |
category | WORDPRESS_ |
post_ | WORDPRESS_ |
nav_ | WORDPRESS_ |