HTTPS webhooks (integrations)

This guide is for a Manager or Primary Owner who configures outbound HTTPS webhooks under Settings → Operations. Webhooks are not email: your server POSTs JSON to URLs you control (Zapier, Make, n8n, or custom workers). Staff notifications and visitor auto-replies are covered in Notifications.

The product does not ship a native HubSpot or Salesforce connector. Patterns for mapping JSON into CRMs live in CRM & tools.

Webhooks never run before a submission row exists. They are separate from SMTP and do not replace staff mail.

  1. submission_created — After intake validates the payload, inserts the row, and attempts staff notification and visitor auto-reply (when enabled). See Notifications — intake order for the full pipeline.
  2. status_changed — Only after a dashboard user saves a new lead status through update_status.php (not part of the initial form submit).
  3. A failed webhook POST does not delete the submission; errors are logged. The lead remains in Inbox & leads.

Important. You cannot reorder “save → email → webhook” from the UI. You enable or disable each webhook row and its event toggles.

Up to ten rows. Each stores a public URL, optional bearer secret, event toggles, optional registry form-key filters, and optional status filters for status_changed.

  1. Create or copy an HTTPS endpoint that accepts POST with Content-Type: application/json.
  2. Open Settings → Operations, scroll to Webhooks, and paste the URL.
  3. Set a Bearer secret when your receiver checks Authorization: Bearer …; the plain secret is stored in wf_config/private.php after save.
  4. Enable On new submission for submission_created or On status change for status_changed (or both when appropriate).
  5. Use status filters so only selected pipeline stages trigger automation when you defer CRM sync until after human review.
  6. Use form key restrictions when only certain registry keys should hit a destination.

The master switch prevents accidental traffic while URLs are half-built.

  1. Turn Webhooks enabled on only after every row is tested.
  2. Save the Operations form.
  3. Submit a test lead and confirm your receiver logged JSON with keys such as event, submission_id, form_name, status, submitted_at, page_url, ip_address, and fields.
  4. When a POST fails, read PHP’s error log for lines prefixed with [wckd-forms webhook] before changing receiver code.

Use this when CRM or Slack should react only after qualification in the inbox.

  1. Change a lead’s status in the dashboard for a row that matches your webhook filters.
  2. Inspect the receiver log and confirm event is status_changed and previous_status matches the old label.
  • event — submission_created or status_changed
  • submission_id, form_name, status, submitted_at, page_url, ip_address
  • fields — object of submitted column values (strings)
  • previous_status — present only for status_changed

Field-by-field mapping examples: CRM & tools.

  • No POST arrives: master webhooks switch is off, the row lacks On new submission, or the URL failed host validation (localhost and private IPs are rejected).
  • 401 from receiver: bearer mismatch between Operations and your worker.
  • CRM sees raw leads too early: leave On new submission off for that URL and enable On status change with tight status filters instead.
  • Expecting webhooks to send email: use Notifications for staff mail and auto-reply.