CF7 to Webhook: Send Contact Form 7 Data to n8n (Step-by-Step)

The most common approach to a CF7 to webhook integration uses the wpcf7_mail_sent action hook. Contact Form 7 fires this hook after a successful 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 widely used. 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 CF7 to webhook integration is handling real traffic: the call is synchronous, so PHP blocks and waits for the remote server to respond before the form submission completes.

Contact Form 7 has over 10 million active installations on WordPress.org — making it one of the most-deployed plugins in the ecosystem. At that scale, silent webhook failure is not an edge case; it accumulates across every site relying on synchronous wp_remote_post() without retry logic.

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

When a CF7 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 typical CF7 submission looks like when it arrives at your n8n webhook. The field names match the name attributes you set in your CF7 form tags.

The payload wraps the full WPCF7_ContactForm object including submitted fields, page url, remote_ip, and user_agent. Use args[0].submission.fields in n8n to access form values directly.

Every webhook delivery attempt is stored in the event log — success or failure. If a CF7 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 contact form submission is often a high-intent signal — someone typing their email and pressing send is more committed than a page view. 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.

Exponential backoff is the industry-standard approach for retryable HTTP operations. AWS documentation on error retries and exponential backoff explains that spacing retries progressively further apart — rather than at fixed intervals — reduces load on a recovering service and improves overall delivery success rates for transient failures.