WP Webhooks / Examples / IvyForms to Webhook

Example · IvyForms

IvyForms Webhooks: Send Form Submissions to n8n (Step-by-Step)

IvyForms doesn't include a built-in webhook feature. To forward form submissions to tools like n8n you need custom code or an additional plugin. This guide covers both approaches — the quick way and the reliable way.

~10 min read Mar 28, 2026

ivyformswebhookn8n

TL;DR

IvyForms has no built-in webhook — add one with the ivyforms/form/after_submission action hook and wp_remote_post
Submission data arrives in the $form and $data parameters passed to your hook callback
For production: wrap the dispatch in a queue-and-retry plugin so submissions aren't dropped when the receiving endpoint is temporarily unavailable

/ Basic Method

Basic IvyForms Webhook Using wp_remote_post

The most direct way to add IvyForms webhook support is the ivyforms/form/after_submission action hook. IvyForms fires this hook after every successful form submission — you hook into it, grab the submitted data, and POST it to your webhook endpoint.

Here's the minimal working code. Add it to your theme's functions.php or a custom plugin:

functions.php — ivyforms webhook (basic)

add_action('ivyforms/form/after_submission', function ($form_id, $submission_data, $form_fields, $entry_id) {
    wp_remote_post('https://your-n8n-url/webhook/test', [
        'headers' => [
            'Content-Type' => 'application/json',
        ],
        'body' => json_encode([
            'form_id'         => $form_id,
            'submission_data' => $submission_data,
            'entry_id'        => $entry_id,
        ]),
    ]);
}, 10, 4);

This works. It's simple and easy to drop in. For a hobby project or an internal form with low submission volume, it does the job.

The problem is what happens in production.

/ Production Reality

Why the Basic IvyForms Webhook Setup Breaks in Production

The wp_remote_post() approach works in development. The problem shows up once your IvyForms webhook is handling real traffic: the call is synchronous, so PHP blocks and waits for the remote server to respond before the form submission completes.

WordPress's wp_remote_post() defaults to a 5-second timeout. Any endpoint that takes longer — a starting n8n instance, a cold-start serverless function, a rate-limited API — causes the form submission to hang visibly for the user, then drop the event silently with no retry and no log entry.

× No retries if the webhook fails. If n8n is restarting, rate-limiting you, or simply returns a 500 — the delivery attempt is gone. The form appeared to submit successfully but your workflow never ran.
× No logging. There's no record of what was sent, when, or what response came back. Debugging a missed submission means checking server logs and hoping the data is still there.
× No visibility into failures. You won't know a submission was lost until someone follows up asking why no one responded. By then it's too late.
× No way to replay submissions. Once the HTTP call fails, the data is gone from the delivery context. You can't re-send it without the user resubmitting the form.
× Slows down form submission for the user. If your n8n webhook takes 3 seconds to acknowledge, every form submission on your site takes 3 extra seconds. If it times out (default: 5s), users see a hang.

Form submissions can fail silently if the receiving service is down. Without retries, that means lost data — and no way to know it happened until someone complains.

/ Better Approach

Reliable Method: Queue-Based Webhooks with Retry and Logging

⚡

This example uses Webhook Actions by Flow Systems — a free WordPress plugin that provides reliable webhook delivery with automatic retry and replay support. It works by queuing webhook dispatch as a background job, so your form submissions are never blocked by a slow or unavailable endpoint.

A reliable IvyForms webhook setup separates two things the basic approach conflates: recording that a submission happened and delivering it to the endpoint.

When an IvyForms form is submitted, a background job is queued immediately. The user gets an instant response — the form submission is complete from their perspective. A cron worker then picks up the job and attempts delivery in the background.

If the delivery fails — because n8n returned a 5xx, hit a rate limit (429), or simply timed out — the job is scheduled for retry with exponential backoff: 1 min, 2 min, 4 min, 8 min, 16 min. Each attempt is logged with the HTTP status code and response body. You can see every success and failure in the WordPress admin.

If all retry attempts are exhausted, the job enters a failed state — visible in the event log, and replayable via the REST API or the admin UI. No data is lost.

/ Setup

Step-by-Step: IvyForms Webhook Setup
with Retry and Logging

1
Install the plugin
Search for this exact description in Plugins → Add Plugin — it narrows the WordPress.org search to exactly one result:

search text — paste into WordPress plugin search
```
FlowSystems
```
Create a new webhook
Go to Webhooks → Add Webhook in the WordPress admin. Give it a name (e.g., "IvyForms → n8n").
3
Select the trigger
Set the WordPress action hook to ivyforms/form/after_submission. This fires once per successful IvyForms submission.

action hook — paste into the trigger field
```
ivyforms/form/after_submission
```
Webhook Actions admin — trigger set to ivyforms/form/after_submission, with a captured IvyForms payload visible in the Payload Mapping panel on the right
Set the webhook URL
Paste your n8n webhook URL (e.g., https://your-n8n-url/webhook/test). The plugin will POST form data to this endpoint on every submission.
Save and test
Submit your IvyForms form. Check the Event Log in the plugin admin to see the delivery status and the payload that was sent.

IvyForms form submitted — the ivyforms/form/after_submission hook fires and Webhook Actions queues the delivery

Webhook Actions event log — IvyForms submission delivered successfully; the Log Details panel shows the full payload that was sent

/ n8n

Setting Up the n8n Webhook

On the n8n side, you need a Webhook node configured to receive POST requests:

Add a Webhook node
In your n8n workflow, add a new node and search for "Webhook".
Set HTTP Method to POST
The plugin sends a JSON POST request, so make sure the Webhook node is set to accept POST.
Copy the webhook URL
n8n will generate a URL like https://your-n8n-url/webhook/test. Copy this and paste it into the plugin's webhook URL field (step 4 above).
Activate and test
Click "Listen for test event" in n8n, then submit your IvyForms form. n8n will display the incoming payload so you can map the fields to subsequent nodes.

n8n Executions — IvyForms submission received by the Webhook node; args[1] field values and args[2] field definitions visible in the output

/ Payload

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": "IvyFormsEntityFieldField",
        "id": 1,
        "label": "Name",
        "type": "text",
        "required": true,
        "value": "Mateusz"
      },
      {
        "__type": "IvyFormsEntityFieldField",
        "id": 2,
        "label": "Email",
        "type": "email",
        "required": true,
        "value": "[email protected]"
      },
      {
        "__type": "IvyFormsEntityFieldField",
        "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. It also includes formId, postId, and referer. args[2] is the field definitions array — each object has id, label, type, and value, so you can join by ID to get human-readable labels in n8n. args[3] is the entry ID (null if entry storage is disabled in IvyForms).

/ Advanced

Advanced: Retry and Debug Failed Submissions via API

Every webhook delivery attempt is stored in the event log — success or failure. If an IvyForms submission didn't reach n8n, you can replay it without asking the user to resubmit.

The plugin exposes a REST API for this:

retry a failed delivery

POST /wp-json/fswa/v1/logs/{id}/retry

// Response
{
  "success": true,
  "message": "Retry queued"
}

Replace {id} with the log entry ID visible in the Event Log. This re-queues the exact payload that was originally sent — no need to reconstruct it.

You can also trigger retries from the WordPress admin UI. Both options are covered in the REST API documentation.

Webhook Actions by Flow Systems event log showing a failed IvyForms webhook delivery with HTTP 500 status, retry scheduled, and the full request payload in the Log Details panel — Webhook Actions event log — IvyForms delivery failed with HTTP 500; next retry already scheduled automatically, full payload preserved for replay

/ Real-World Reliability

Why Your IvyForms Webhook Integration
Needs Retry Support

A form submission is often a high-intent signal — someone who fills out and submits a form is more committed than a passive visitor. Losing that data silently is costly.

With a bare wp_remote_post() call, any of these common scenarios causes permanent data loss:

n8n restarts during deployment. Your instance hits a memory limit and returns 500. The incoming webhook URL changes and the old one starts returning 404. A rate limit is hit during a campaign burst.

None of these are edge cases in real production environments. A queue with retries means these scenarios become recoverable failures instead of silent data loss. The event log means you can diagnose and replay — instead of guessing.

Stripe's webhook best practices guide recommends building retry logic with exponential backoff as a baseline expectation — not an edge case. The same applies to any form plugin sending data to an external endpoint: the receiving service will be unavailable at some point, and the question is whether that results in a recoverable delay or permanent data loss.

Without retries, a single n8n restart during business hours can mean lost submissions. With retry and replay support, the same event becomes a recoverable blip — automatically resolved within minutes.

/Notes

→ Webhook Actions by Flow Systems — plugin overview

→ From do_action to HTTP — how IvyForms hooks are discovered, field objects normalized, and submission values merged into the payload

→ WordPress Webhook REST API — retry and replay documentation

→ Why WP-Cron is not enough for production webhook delivery

→ Why WordPress webhooks silently fail in production

→ All WordPress webhook automation examples

FAQ

Common questions always ask.

Don't see yours? Open an issue on GitHub or check the full reference in the API docs.

How do I add a webhook to IvyForms? +

IvyForms doesn't include a built-in webhook feature. To add a webhook to IvyForms, hook into the ivyforms/form/after_submission action and use wp_remote_post() to forward submission data to your endpoint. For production use, a queue-based plugin like Webhook Actions by Flow Systems handles this reliably with automatic retries and delivery logging.

Does IvyForms support webhooks natively? +

Not natively. IvyForms doesn't ship with a built-in webhook feature. To send form data to a webhook endpoint you need custom code using the ivyforms/form/after_submission action hook, or a plugin that handles webhook dispatch for you.

How do I send IvyForms submissions to n8n? +

Hook into the ivyforms/form/after_submission action (4 args: $formId, $submissionData, $formFields, $entryId), then post the data to your n8n webhook URL using wp_remote_post(). Note that $submissionData keys are numeric field IDs — use $formFields to map them to labels. For reliable delivery with retries, use a queue-based plugin like Webhook Actions by Flow Systems that handles failures automatically.

What happens if my n8n webhook is down when IvyForms submits? +

With a bare wp_remote_post() call, the data is lost silently — there's no retry and no log entry. With a queue-based system, the failed delivery is stored and retried automatically with exponential backoff (1 min, 2 min, 4 min, 8 min, 16 min). You can also replay any failed submission manually from the WordPress admin.

Can I retry failed IvyForms webhook deliveries? +

Yes, if you use a plugin with retry support. Webhook Actions by Flow Systems retries failed deliveries automatically and also exposes a REST API endpoint (POST /wp-json/fswa/v1/logs/{id}/retry) that lets you replay any past submission — including successful ones.

Does wp_remote_post slow down IvyForms submissions? +

Yes. wp_remote_post() is synchronous — PHP blocks and waits for the remote server to respond before the form submission completes. If your n8n instance is slow or unavailable, users experience a delayed or failed form submission. A queue-based approach dispatches the webhook in the background so the user sees an instant response regardless of endpoint latency.

More examples