For the complete documentation index, see llms.txt. This page is also available as Markdown.

πŸͺWebhooks

Send every Dapta Forms submission as a JSON POST to a URL you control. Set the endpoint, an optional signing secret, choose whether partial and complete submissions trigger it, send a test, and switch

A webhook POSTs each submission as JSON to an endpoint you own: your CRM, an automation tool, a spreadsheet connector, or your own backend. You set it up per form from the Connect tab. Delivery is durable: a submission is stored first and the webhook is queued, retried on failure, and logged so you can see what was sent and what your endpoint answered.

This page covers the webhook card. The request format is on Payload & headers reference, authentication on Verify the signature, and testing on Test & delivery history.


Step 1: Open your form in the editor and click Connect in the top bar. In the Integrations section, find the Webhook card ("POST each submission as JSON to a URL you control.") and turn the switch on. The label changes from Disabled to Enabled and the card expands.

The Webhook card with the Enabled switch turned on, showing the Endpoint URL, Signing secret and Trigger on fields
Turn the switch on to reveal the webhook settings.

Step 2: Paste your URL in Endpoint URL. It must start with https:// (plain http:// is accepted only for localhost, for local development). Anything else shows "Enter a valid https:// URL (plain http is allowed only for localhost)." As soon as the URL is valid it is saved: the footer reads Changes saved automatically, and the webhook is live on the published form from that moment.

Step 3 (recommended): Type a Signing secret (optional). When set, each request is signed with HMAC-SHA256 in the X-Forms-Signature header so your endpoint can verify the request really came from Dapta Forms. After you leave the field it is masked and reads A secret is set. Leave blank to keep it, or type a new one. The secret is never shown again.

The Webhook card with an Endpoint URL filled in and a Signing secret typed
Endpoint URL and signing secret. Both save automatically.

Step 4: Under Trigger on, choose which submissions are sent: Partial submissions, Complete submissions, or both. Both are ticked by default and at least one must stay ticked.

The Trigger on checkboxes for Partial submissions and Complete submissions
Choose which submissions are sent to this webhook.
  • A partial submission is sent when the respondent passes the form's Partial submit point (for example right after the email question) and has not finished yet.

  • A complete submission is sent when the respondent reaches the end. The same session produces one partial and then one complete delivery; both carry the same submission.id, and phase tells them apart.


Step 5: Click Send test. Dapta Forms posts one sample body in the real shape, signed with your secret, with made-up answers and "test": true in the data. A green toast Test delivered. Your endpoint accepted it. means your endpoint answered with a 2xx status. If it did not, the toast explains what came back (see Test & delivery history).

The Send test button with a toast that reads Test delivered. Your endpoint accepted it.
A successful test. The sample request reaches your endpoint for real.

⚠️ Note: Send test is available to Owners and Admins. Any member can edit the webhook fields.


Settings reference

Setting
What it does

Enabled / Disabled switch

Turns the webhook on or off without losing its settings. Off means nothing is queued for this webhook.

Endpoint URL

The https:// URL that receives the POST. Clearing the field removes the webhook. Private, loopback, link-local and cloud metadata addresses are blocked before sending.

Send test

Posts one signed sample request. Disabled until a URL is saved (otherwise: "Save a webhook URL first.").

Signing secret (optional)

Key for the HMAC-SHA256 signature in X-Forms-Signature. Leave blank to keep the current one; type a new value to rotate it.

Trigger on

Partial submissions and/or Complete submissions. At least one.

Webhook history

A {n} deliveries chip (or a red {n} failed) and the View history button that opens the delivery log.

How a delivery behaves

  • Method POST, header content-type: application/json, body = the JSON envelope described in Payload & headers reference.

  • Your endpoint has 10 seconds to answer. Any 2xx counts as delivered. A 3xx is never followed and counts as a failure, as do 4xx, 5xx, timeouts and network errors.

  • Failures are retried automatically with increasing delays (1 s, 2 s, 4 s, 8 s…), up to 5 attempts. After that the delivery is marked Failed and kept in the history. See Delivery, retries & history.

  • Nothing is sent to a webhook that is Disabled, and a submission is always stored even if the webhook is down.

Several webhooks on one form

Each form can hold more than one webhook, but the card edits only the first. When others exist you see This form has {count} more webhook(s) with the note that they keep running exactly as they are and are saved untouched, just not editable from here. All of them are listed in the Webhooks inventory on the Connections page.

πŸ’‘ Tip: UTM parameters on the public link (utm_source, utm_medium, …) ride along in every webhook body, nested under data.utm and again at the top level under utm, so your endpoint can attribute the lead.

What's next

Last updated