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

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:

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.

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.

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.

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

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.

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).

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:

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.

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.