Manage Webhook Actions with AI

What we learned testing it

Behavior the ability descriptions do not mention.

• New webhooks are created switched off. While off, a webhook still records the payload when its event fires, so the AI can map against a real order or submission before anything is sent. Until the event has fired once on your site there is nothing to map, and the AI should ask you to fire it rather than guess.
• A webhook with no field mapping sends the whole event payload. For a WooCommerce order in our test that was the customer's name, email, address and phone and the order's IP address; for a Contact Form 7 submission, the visitor's IP address and browser. Map the fields you need with includeUnmapped false to send only those.
• What the AI reads through the abilities is scrubbed: fields named like passwords, tokens, keys and secrets come back as [redacted], WooCommerce order meta key names included. What the webhook delivers is not scrubbed, and neither are the plugin's own REST routes: clearing a capture returns the capture the webhook falls back to, order key included, so the recipes ask for the reset field only.
• Testing a delivery, turning a webhook on or off, sending a test alert and probing with an explicit PUT, PATCH or DELETE are refused by Webhook Actions until the call says confirmed (a probe that only names a webhook whose own method is PUT, PATCH or DELETE is not). The AI adds that itself and WPVibe shows no approval page for them, so the recipes ask you first. WPVibe's approval page appears for deleting a webhook or a snippet and for attaching a snippet to a webhook. Editing a live webhook needs no confirmation.
• Deliveries are queued and sent in the background with retries, by Action Scheduler when a plugin such as WooCommerce provides it, or WP-Cron otherwise. On our test site they arrived within about a minute. On a site with little traffic and no server cron job they can wait for the next visit.
• Retrying an entry from the delivery log reuses the settings stored with the failed job: after we fixed a webhook's URL, a retry still went to the old one and failed again. Sending the logged payload as a test delivery goes to the fixed webhook. Replay works only on deliveries that succeeded or were skipped.
• The Contact Form 7 hook wpcf7_mail_sent fires only after the form's notification email went out. If the site cannot send email, nothing is delivered.
• Notification channels hold secrets, so they are added only in Webhook Actions, Notifications, Channels. The AI can create rules that use them and send a test, which is a real message.
• Code Glue snippets are PHP that runs on your site. Test-running one with preview-snippet runs its code with no WPVibe approval page; attaching one to a webhook does show it. Writing or test-running a snippet is refused where file editing is switched off (DISALLOW_FILE_EDIT).
• A probe is a real request: an empty JSON body for POST, which a live Zapier, Make or n8n workflow may run on, so the recipes ask first, and leave it out of a new build where n8n's test URL or Make's data structure listener would take it as the sample. It sends only the URL and vault credential, not custom headers or URL parameters, and some endpoints answer 400 or 422 to an empty body even when they work. Probes to private or local addresses, or to ports other than 80, 443 and 8080, are refused.
• Webhook Actions delivers only to https URLs on public hosts, on port 443 or 8080. A plain http URL can be saved, but every delivery fails at once with Invalid URL format, even when a probe to it succeeds.
• Three abilities have not run yet in our test: delete-webhook, delete-snippet and assign-snippet waited on WPVibe's approval page. They are marked Registered.
• To keep a connected AI read-only, turn off Settings, Let connected AI tools build webhooks: the abilities that change or send anything, plus list-credentials, then disappear. Webhook Actions' own Build with AI agent is not affected.