IvyForms Webhooks: Built-In Integration, Configured by AI

Describe It Once — The Agent Builds It

Open Webhook Actions in the WordPress admin and type:

prompt — paste into Build with AI

When an IvyForms form is submitted, send it as JSON to my n8n webhook: https://your-n8n-url/webhook/test

Click to expand

The agent gathers context first — you'll see read-only ability chips like list_triggers and get_trigger_schema. IvyForms is one of the plugin's built-in integrations, so the agent selects ivyforms/form/after_submission itself and knows the payload shape it produces.

It then proposes an ordered plan: create the webhook, point it at your n8n URL, and map the numeric field IDs to readable keys. With "Review plan before running" enabled you can edit any step before it executes.

Click to expand

When the run finishes you get "Build complete." with a one-click enable toggle; new webhooks are always created disabled until you confirm.

Click to expand

Prefer to Set It Up by Hand?

The same result takes five steps in the admin UI — no AI provider needed:

1. 1
   Install the plugin

   Search for FlowSystems in Plugins → Add Plugin — it narrows the WordPress.org search to exactly one result.

2. 2
   Create a new webhook

   Go to Webhooks → Add Webhook, name it (e.g., "IvyForms → n8n").

3. 3
   Select the trigger

   Set the WordPress action hook to ivyforms/form/after_submission — it fires once per successful IvyForms submission.

   action hook — paste into the trigger field

   ivyforms/form/after_submission

   ⎘

   Click to expand

4. 4
   Set the n8n webhook URL

   In n8n, add a Webhook node, set HTTP Method to POST, and copy its URL into the plugin's webhook URL field.

5. 5
   Save and test

   Submit your IvyForms form and check the Event Log for the delivery status and payload. In n8n, "Listen for test event" shows the incoming data for mapping to subsequent nodes.

   Click to expand

Writing the integration yourself against the hook? The signature (4 args: $formId, $submissionData, $formFields, $entryId), a working wp_remote_post() example, and the field-ID-to-label mapping are covered in the ivyforms/form/after_submission hook reference.

Example Payload

Here's what a real IvyForms submission looks like when it arrives at your n8n webhook. args[1] contains the submitted values keyed by numeric field ID (not field name), plus formId, postId, and referer. args[2] is the full field definition array — use it to map IDs to human-readable labels.

POST body — application/json

{
  "event": {
    "id": "c3194779-575a-432e-be87-2e739c4a7a5b",
    "timestamp": "2026-03-27T21:59:03Z",
    "version": "1.0"
  },
  "hook": "ivyforms/form/after_submission",
  "args": [
    1,
    {
      "1": "Mateusz",
      "2": "[email protected]",
      "3": "testing webhook",
      "formId": 1,
      "postId": 20,
      "referer": ""
    },
    [
      {
        "__type": "IvyForms\Entity\Field\Field",
        "id": 1,
        "label": "Name",
        "type": "text",
        "required": true,
        "value": "Mateusz"
      },
      {
        "__type": "IvyForms\Entity\Field\Field",
        "id": 2,
        "label": "Email",
        "type": "email",
        "required": true,
        "value": "[email protected]"
      },
      {
        "__type": "IvyForms\Entity\Field\Field",
        "id": 3,
        "label": "Message",
        "type": "textarea",
        "required": false,
        "value": "testing webhook"
      }
    ],
    3
  ],
  "timestamp": 1774648743,
  "site": {
    "url": "https://webhook-actions.local"
  }
}

args[0] is the form ID. args[1] is the submission data — field values are keyed by numeric field ID ("1", "2", "3"…), not by label. args[2] is the field definitions array — each object has id, label, type, and value. args[3] is the entry ID (null if entry storage is disabled in IvyForms). Let Build with AI apply a field mapping and n8n receives flat keys like name and email instead.

What You Get Beyond the Setup

Every delivery is dispatched from a background queue, so form submissions are never blocked by a slow or unavailable endpoint. Failures retry automatically with exponential backoff — 1 min, 2 min, 4 min, 8 min, 5 attempts — and every attempt is logged with status code and response body. Anything that exhausts its retries stays in the event log, replayable from the admin UI or via the REST API (POST /wp-json/fswa/v1/logs/{id}/retry) — without asking the user to resubmit.

Click to expand