# Why We Didn't Build Another Plugin-by-Plugin Integrations List

If you've worked with WordPress long enough, you've seen the same pattern in every integration plugin out there: a settings screen listing which plugins are supported, and a roadmap post promising more are coming. It works fine until a client's site uses something that isn't on the list, and you're back to writing `add_action()` calls by hand.

That kept happening to us. One client wanted a Telegram alert on every form submission. Another had a HubSpot connection acting up, so we routed things through Zapier instead and let it push into HubSpot from there — actually easier to debug, since you can see each step instead of it being a black box. A third wanted different Slack notifications for different WooCommerce events. Different destinations every time, but the same shape of problem underneath.

So when we sat down to build Webhook Manager, we asked a different question than most integration plugins ask. Not "which plugins should we support" — more "how do we support the pattern instead of the plugin."

Here's the thing: every WordPress plugin, however obscure, talks through action hooks. If you can safely listen to any hook and serialize whatever comes through it, you don't need a supported-plugins list at all.

The listening part is easy — `add_action()` with `PHP_INT_MAX`

as the argument count handles that in a few lines. The hard part is what to do with what comes through. A raw hook argument is often just an integer ID, or a native object stuffed with internal plugin noise you don't want anywhere near a webhook payload.

So there's a serialization layer that:

*   Flattens known WordPress types (posts, users, terms, comments) into safe, common fields
    
*   Recognizes anything exposing a `get_data()` method (covers a good chunk of WooCommerce-adjacent plugins) and uses that directly
    
*   Attaches a full expanded object alongside documented ID arguments — `post_id => 51` becomes `post_id => 51, post => {...}` automatically
    
*   Makes a best-effort guess on undocumented bare integers against posts/users/terms/orders, and attaches whatever matches — additively, without ever touching the raw value
    

That last part was the genuinely interesting engineering problem: how do you add real value to an unlabeled integer when WordPress never exposes a hook's parameter names at runtime? The answer we landed on — guess safely, attach generously, never discard the original — turned out to work well in practice.

We still built dedicated adapters for the handful of form plugins and WooCommerce, because those specifically benefit from hand-tuned payload cleanup — stripping nonces, reCAPTCHA tokens, that kind of thing. But the generic adapter is what makes the whole thing future-proof. It covers plugins we've never used, including ones that don't exist yet.

Live and free on [WordPress.org](https://wordpress.org/plugins/webequipe-webhook-manager/), source context included in the plugin itself if you want to poke around.