Send form submissions as an HTTP POST request to any URL — works with Zapier, Make (Integromat), n8n, or your own custom endpoint. The Webhook integration is built into the free Contactum plugin — no Pro required.
If you’re using Contactum Pro and need multiple webhook destinations on the same form (rather than just one), see the dedicated n8n or Zapier Pro modules instead — those support any number of feeds per form plus (for n8n) a custom auth header. This free Webhook integration supports exactly one destination per form.
Requirements #
- A destination URL that accepts an HTTP POST request — a Zapier “Catch Hook” trigger, a Make/n8n webhook, or any custom endpoint you control
1. Set a Default Webhook URL (Optional) #
- Go to Contactum → Settings → Integrations → Webhook.
- Optionally set a Default Webhook URL — used as a fallback for any form that has Webhook enabled but no URL of its own.
- Choose a Default Request Format: JSON (recommended) or Form Encoded.
This global step is entirely optional — most users skip it and just set a URL per form (below).
2. Enable Webhook on a Specific Form #
- Open the form in the builder.
- Go to Form Settings → Integrations.
- Toggle Enable Webhook on, then click Configure.
3. Configure the Destination #
| Field | Required | Description |
|---|---|---|
| Webhook URL | No* | Where to send the submission, e.g. https://hooks.zapier.com/hooks/catch/.... *Required unless a Default Webhook URL is set globally |
| Request Format | No | JSON (recommended) or Form Encoded. Falls back to the global default if left unset |
There’s no field mapping — every field on the form is sent automatically.
4. How It Works #
When a visitor submits the form:
- Contactum checks the form has Webhook enabled and resolves a URL — the form’s own, or the global default if the form didn’t set one.
- Every submitted field is sent, keyed by its label (not internal name). With JSON format, the payload looks like:
{
"entry_id": 42,
"form_id": 7,
"form_name": "Contact Us",
"submitted_at": "2026-05-22 10:00:00",
"fields": {
"Name": "Jane Doe",
"Email": "jane@example.com",
"Message": "Hello!"
}
}
With Form Encoded, the same data is flattened — entry_id, form_id, form_name, submitted_at, and each field become individual top-level POST fields instead of a nested fields object.
- The request is sent in the background — Contactum doesn’t wait for your endpoint to respond before finishing the visitor’s submission, so a slow or unreachable webhook never delays or blocks the form.
Because delivery isn’t confirmed at submission time, every dispatch is recorded in Contactum’s activity log and API Log as “queued”/”pending, delivery not confirmed.” You can check there to see exactly what was sent, and retry a specific submission — which does wait for a real response and updates the log to success or failed.
Use Send Test in the Configure dialog to fire a one-off synthetic payload at your URL immediately, to confirm it’s reachable before relying on real submissions.
Troubleshooting #
My endpoint isn’t receiving anything #
- Confirm the form has Enable Webhook toggled on and saved, and has a URL (its own, or a global default).
- Use Send Test to check for an immediate pass/fail.
- Check the API Log (Contactum → Tools → API Log, if available) — every real dispatch is recorded there.
The log shows “pending” and never updates #
- This just means delivery wasn’t confirmed at submission time (by design, so it never slows down your visitors). Use the Retry button on that log entry to resend it and get a confirmed result.
I need more than one destination per form #
- The free Webhook integration supports only one URL per form. If you’re on Contactum Pro, use the n8n or Zapier modules instead — both support multiple destinations on the same form.
Notes #
- Included in the free Contactum plugin — no Pro upgrade required.
- No account/API key — any URL that accepts POST requests will work.
- Credentials storage: the optional global default is stored in
wp_optionsunder the keycontactum_webhook; per-form URLs are stored on the form itself. - A failed or unconfirmed delivery never blocks the form — the visitor’s experience is unaffected either way.