Webhook Actions – build automations and integrations with AI help vs WP Consent API

Describe the integration you want. The AI builds it. Webhook Actions ships with Build with AI — an in-admin agent that turns a plain-language request like “When a Contact Form 7 form is submitted, send it as JSON to my n8n webhook” into a working, tested automation. The agent proposes a plan you can review and edit, then creates the webhook, captures a real example payload from your site, maps the fields, sets dispatch conditions, probes your endpoint, and sends a test delivery. Nothing goes live without your confirmation — new webhooks are always created disabled, and you can undo the last change with one click. 📖 Full documentation at wpwebhooks.org/docs/ What you can connect Sources — anything in WordPress that fires an action. Webhook Actions turns any do_action into a trigger, so form submissions, WooCommerce orders, user registrations, post publishes and your own custom plugin events can all start an automation. That covers Elementor Forms, WPForms, Forminator, Fluent Forms, Gravity Forms, WooCommerce and your own code — there is no per-plugin add-on to hunt down. Contact Form 7 and IvyForms go one step further with built-in support: their submissions are normalized into clean JSON payloads automatically. Destinations — any HTTP endpoint. The plugin sends outgoing webhooks to anything that accepts a request: an n8n, Make, Zapier or Pabbly webhook node, a Slack or Discord incoming-webhook URL for order and form notifications, Airtable, Google Sheets, Mailchimp, HubSpot, Salesforce, Notion, your CRM, an internal microservice, or an AI agent API. There are no bundled per-service connectors and none are needed — point a webhook at a URL, map the fields, and send. Every delivery is queued, retried on failure and logged with full request and response history. That makes it a no-code way to sync WordPress data outward: describe what you want in chat and let the AI build it, or wire it up by hand in the admin UI. No PHP required either way. Bring your own AI — free options included WordPress 7.0 AI Client — if your site already has an AI provider connected (Settings → Connectors), the builder uses it directly; the plugin stores no keys Your own API key — connect Anthropic, OpenAI, or Google in the builder; keys are encrypted in the Credentials Vault and never returned over the API Free to run — a free Google AI Studio key gives you Gemini at no cost: step-by-step tutorial Automatic fallback — if a provider is rate-limited mid-build, the agent switches to another connected provider and keeps going What the AI works from The agent doesn’t guess — it works from your site’s real data. It maps fields against actually captured payloads, edits existing webhooks by name or id instead of duplicating them, validates endpoints with a guarded probe (SSRF-protected, secrets always redacted), and verifies the result with a real test delivery. Every operation is also published as a WordPress Ability, so external AI tools (Claude Code, Cursor) can drive the same toolset over MCP with scoped API tokens. The engine underneath (free) Turn any WordPress do_action into a first-class automation trigger your CRMs, n8n flows, AI agents, and internal services can consume — every dispatch is an outgoing webhook you fully control Persistent delivery queue with smart retry and exponential backoff — powered by WP-Cron, auto-upgrades to Action Scheduler or System Cron when available, (Pro) External Cron for guaranteed reliability Per-event UUID and ISO 8601 timestamp — enable downstream deduplication Delivery logs with full attempt history, request/response inspection, replay, and bulk retry Synchronous execution mode — fire inline without queue delay Payload mapping — rename, restructure, exclude, and type-cast fields with dot-notation paths Conditional dispatch — filter events by payload field values before dispatch, so a Slack notification or a CRM sync only fires when it should HTTP method, custom headers, and URL query parameters per webhook Dynamic endpoint URLs — {{ field.path }} placeholders resolved at dispatch time (free via fswa_webhook_url filter) Webhook Chains — wire 2xx completions to downstream webhooks with full observability Import & Export — move webhooks and chains between sites as portable JSON (triggers, field mapping, and conditions included; Code Glue with Pro), with strict validation and a per-item result summary on import Markdown descriptions — document what each webhook and chain does inline, with a Write/Preview toggle while editing Credentials Vault — store reusable auth secrets (Bearer, Basic, API key, custom) encrypted at rest; reference them from webhooks instead of pasting raw Authorization headers. Secrets are write-only over the API — never returned, only a masked hint Activity History — persistent audit log of every admin and API-token action Built-in CF7 and IvyForms integrations — structured payloads, no extra plugins Action Scheduler auto-detection — more reliable delivery on high-traffic sites Fully translatable — the entire admin interface and all server-side strings are internationalized; ships with Polish, Simplified Chinese, and Dutch, and is compatible with WPML and Polylang String Translation Full REST API with scoped API token authentication (read / operational / full / agent) — the agent scope grants full write access for AI assistants while never exposing stored secrets Developer extensibility — 16 filters and 7 action hooks (reference) Pro features AI credits included — Build with AI runs through the hosted WP Webhooks AI service on every Pro plan: no API keys to create, no provider accounts, a monthly credit allowance that renews automatically, and a live credits counter in the builder. Your own keys and WordPress connectors stay available any time AI writes Code Glue for you — the agent drafts PHP snippets, test-runs them against your real captured payloads, and assigns them to webhooks (with your confirmation) for pre-dispatch payload enrichment or post-dispatch side effects AI sets advanced conditions — with Pro the agent can propose multi-rule AND/OR condition groups instead of a single rule Code Glue — attach PHP snippets to any webhook+trigger (pre-dispatch payload enrichment, post-dispatch side effects) External Cron — replace unreliable visitor-triggered WP-Cron with a managed external pinger, provisioned automatically on license activation. Two modes: plugin queue endpoint (down to 20 s interval, configurable batch size) or WP-Cron endpoint (60 s, covers all WordPress background work). No server crontab or external dashboard — controlled entirely from wp-admin, with a live heartbeat chart and inline error alerts Unlimited conditions per trigger with AND/OR groups Per-webhook retry limit and backoff strategy overrides Dynamic URL templates — {{ }} syntax with no custom PHP required See pricing and upgrade → Examples Send Contact Form 7 submissions to a webhook (n8n demo) Send Gravity Forms Submissions to n8n Send IvyForms submissions to a webhook (n8n demo) WooCommerce orders to n8n on completion — wired up with a Claude Code agent WooCommerce to HubSpot integration — sync orders, contacts, and deals with no custom code

WP Consent API is a plugin that standardizes the communication of accepted consent categories between plugins. It requires a cookie banner plugin and, at least, one other plugin that supports the WP Consent API. With this plugin, all supporting plugins can use the same set of methods to read and register the current consent category, allowing consent management plugins and other plugins to work together, improving compliance with privacy laws. WARNING: the plugin itself will not handle consent. It will show you how many plugins you have without Consent API support and will improve compliance on your site by ensuring smooth communication between cookie banner plugins and plugins that set cookies or track user data. What problem does this plugin solve? Currently, it is possible for a consent management plugin to block third-party services like Facebook, Google Maps, Twitter, etc. But if a WordPress plugin places a PHP cookie, a consent management plugin cannot prevent this. Secondly, some plugins integrate the tracking code on the clientside in javascript files that, when blocked, break the site. Or, if such a plugin’s javascript is minified, causing the URL to be unrecognizable and won’t get detected by an automatic blocking script. Lastly, the blocking approach requires a list of all types of URL’s that tracks data. A generic API where plugins adhere to can greatly facilitate a webmaster in getting a site compliant. Does usage of this API prevent third-party services from tracking user data? Primary this API is aimed at compliant first-party cookies or tracking by WordPress plugins. If such a plugin triggers, for example, Facebook, usage of this API will be of help. If a user embeds a Facebook iframe, a blocking tool is needed that initially disables the iframe and or scripts. Third-party scripts have to blocked by blocking functionality in a consent management plugin. To do this in core would be to intrusive, and is also not applicable to all users: only users with visitors from opt-in regions such as the European Union require such a feature. Such a feature also has a risk of breaking things. Additionally, blocking these and showing a nice placeholder requires even more sophisticated code, all of which should in my opinion not be part of WordPress core, for the same reasons. How does it work? There are two indicators that together tell if consent is given for a specific consent category, e.g., “marketing”: 1) the region based consent_type, which can be opt-in, opt-out, or other possible consent_types; 2) and the visitor’s choice: not set, allow, or deny. The consent_type is a function that wraps a filter, “wp_get_consent_type”. If there’s no consent management plugin to set it, it will return false. This will cause all consent categories to return true, allowing cookies to be set on all categories. If opt-in is set using this filter, a category will only return true if the value of the visitor’s choice is “allow”. If the region based consent_type is opt-out, it will return true if the visitor’s choice is not set or is “allow”. Clientside, a consent management plugin can dynamically manipulate the consent type and set several cookie categories. A plugin can use a hook to listen for changes or check the value of a given category. Categories and most other stuff can be extended with a filter. Existing integrations Categorized, and sorted alphabetically Example plugin Example plugin. The plugin basically consists of a shortcode, with a div that shows a tracking or not tracking message. No actual tracking is done 🙂 Consent Management Providers Abconsent Sirdata CMP. Beautiful Cookie Consent Banner. Clickio Consent Cookie Consent CMP. Complianz GDPR/CCPA. Consent Studio. consentmanager. Conzent. Cookiebot. CookieFirst. CookieHub. CookieTractor. CookieYes – Cookie Banner for Cookie Consent. GDPR Cookie Compliance. GDPR Cookie Consent Plugin – CCPA Ready. GetTerms. iubenda | All-in-one Compliance. Lawwwing. Pressidium Cookie Consent. TrustArc Cookie Consent Manager Consent Requiring Plugins AddToAny. AFL UTM Tracker Plugin. Burst Statistics. Google Site Kit. Pixel Manager for WooCommerce. Woo. WP Statistics. Demo site wpconsentapi.org Below are the plugins used to set up the demo site: Complianz The example plugin javascript, consent management plugin //set consent type window.wp_consent_type = 'optin' //dispatch event when consent type is defined. This is useful if the region is detected server side, so the consent type is defined later during the pageload let event = new CustomEvent('wp_consent_type_defined'); document.dispatchEvent( event ); //consent management plugin sets cookie when consent category value changes wp_set_consent('marketing', 'allow'); javascript, tracking plugin //listen to consent change event document.addEventListener("wp_listen_for_consent_change", function (e) { var changedConsentCategory = e.detail; for (var key in changedConsentCategory) { if (changedConsentCategory.hasOwnProperty(key)) { if (key === 'marketing' && changedConsentCategory[key] === 'allow') { console.log("just given consent, track user") } } } }); //basic implementation of consent check: if (wp_has_consent('marketing')){ activateMarketing(); console.log("set marketing stuff now!"); } else { console.log("No marketing stuff please!"); } PHP //declare compliance with consent level API $plugin = plugin_basename( __FILE__ ); add_filter( "wp_consent_api_registered_{$plugin}", '__return_true' ); /** * Example how a plugin can register cookies with the consent API * These cookies can then be shown on the front-end, to the user, with wp_get_cookie_info() */ function my_wordpress_register_cookies(){ if ( function_exists( 'wp_add_cookie_info' ) ) { wp_add_cookie_info( 'AMP_token', 'AMP', 'marketing', __( 'Session' ), __( 'Store a unique User ID.' ) ); } } add_action('plugins_loaded', 'my_wordpress_register_cookies'); if (wp_has_consent('marketing')){ //do marketing stuff } Service-level consent In addition to category-based consent, the API supports service-level consent control. This allows consent management plugins to grant or deny consent for specific services (like ‘google-analytics’ or ‘facebook-pixel’) independently from their category. When checking service consent with wp_has_service_consent(), the API first checks if explicit consent exists for that service. If no explicit consent is set, it falls back to the consent status of the service’s category. This enables fine-grained control: a user might accept statistics cookies in general, but explicitly deny a specific analytics service. Service consent can be checked and set both server-side (PHP) and client-side (JavaScript): PHP: //check if a specific service has consent if ( wp_has_service_consent( 'google-analytics' ) ) { //activate google analytics } //check if a service is explicitly denied if ( wp_is_service_denied( 'facebook-pixel' ) ) { //service was explicitly denied by user } //set service consent wp_set_service_consent( 'google-analytics', true ); //grant consent wp_set_service_consent( 'facebook-pixel', false ); //deny consent //listen for service consent changes add_action( 'wp_consent_service_changed', function( $service, $consented ) { error_log( "Service {$service} consent changed to: " . ( $consented ? 'granted' : 'denied' ) ); }, 10, 2 ); JavaScript: //check service consent if ( wp_has_service_consent( 'youtube' ) ) { //activate tracking } //check if explicitly denied if ( wp_is_service_denied( 'facebook-pixel' ) ) { //service denied } //set service consent wp_set_service_consent( 'youtube', true ); //listen for service consent changes document.addEventListener( 'wp_consent_api_status_change_service', function( e ) { console.log( 'Service: ' + e.detail.service + ', consented: ' + e.detail.value ); }); Any code suggestions? We’re on GitHub as well!