Forward submission JSON to your own middleware

This guide is for a technical admin or integrator who already enabled HTTPS webhooks under Settings → Operations. You will map WCKD Forms’ JSON POSTs into HubSpot, Salesforce, Slack Incoming Webhooks, queues, or other HTTPS APIs using Zapier, Make, n8n, or custom code. The product stores submissions in MySQL and emits webhooks; it does not ship OAuth flows or native CRM apps.

You align expectations with the fixed intake pipeline: Notifications — intake order and Webhooks — when POSTs fire.

  1. Confirm the submission row exists in your database before any webhook fires for submission_created.
  2. Assume your HTTPS endpoint receives application/json after staff mail attempts for new rows.
  3. Assume status_changed POSTs happen only after a dashboard user saves a new status.

Receivers branch on event type and map fields into CRM columns.

  1. Expect top-level keys event, submission_id, form_name, status, submitted_at, page_url, ip_address, and fields (object of string values).
  2. Expect previous_status only when event equals status_changed.
  3. Branch on form_name when two registry keys reuse similar field names with different meanings.

Zapier, Make, or n8n issues a public HTTPS URL your WCKD Forms server can reach (private IPs and localhost are rejected by validation).

  1. Create a Zapier Webhooks by Zapier → Catch Hook, a Make Custom webhook, or an n8n Webhook node.
  2. Copy the HTTPS URL the tool shows.
  3. Paste it into Settings → Operations → Webhooks with the toggles documented in Webhooks.

OAuth credentials for Salesforce or HubSpot stay inside the automation tool or your worker, not inside WCKD Forms.

  1. Add an action step that creates or updates a CRM record using properties from the webhook body (for example map fields.email to the CRM email column).
  2. For Slack, either post the raw JSON to an Incoming Webhook URL or format a message in the automation layer.
  3. Handle required CRM fields (for example Salesforce Lead Company) with defaults or validation inside your scenario.

You avoid pushing unqualified rows into downstream systems.

  1. Use On new submission when every stored row should sync automatically.
  2. Use On status change with status filters when only reviewed stages (for example a “Qualified” label) should trigger CRM writes.
  3. Save Operations and test both a fresh submission and a status edit.

You confirm replays or partial failures do not corrupt downstream data.

  1. Use submission_id as a dedupe key in your worker when the automation tool may retry POSTs.
  2. Force a controlled failure (wrong bearer token) and confirm your logs show the rejection while submissions still exist in WCKD Forms.
  • Expecting OAuth inside WCKD Forms: connect CRMs from middleware; the dashboard only stores HTTPS URLs and bearer strings.
  • Mapping fields that do not exist on every form: guard each mapping with a conditional on form_name or presence checks inside fields.
  • Posting to http://: validation requires https:// for webhook destinations.