🔂Delivery, retries & history
How Dapta Forms delivers submissions to webhooks, HubSpot and email without ever blocking a respondent: the queue, the retry schedule with backoff, what Delivered, In progress, Failed and Skipped mean
Every integration in Dapta Forms follows the same rule: store the submission first, deliver afterwards, retry on failure, and keep a log. This page explains that pipeline so you know what to expect when an endpoint is slow, a CRM is down, or a respondent submits twice.
Nothing blocks a submission
When a respondent passes the partial submit point or finishes the form, their answers are saved immediately and they see the next step or the ending screen. Only then does Dapta Forms queue one delivery per enabled integration:
Webhook
One POST per webhook
Partial and/or complete, per the Trigger on boxes
HubSpot
Contact upsert and mapped properties
Partial and complete (score, outcome, static properties, note and form-submission activity only on complete)
Emails
New submission notice and Respondent confirmation
Complete only
Booking sync
HubSpot booking properties
After a scheduler booking
A slow or broken destination therefore never slows the respondent down, and it never loses the answers: the submission is already in Submissions and the CSV export before any delivery is attempted.
Retry schedule
A delivery is picked up within a few seconds. If it fails (non-2xx status, redirect, timeout after 10 seconds, network error, provider error) it is retried with exponential backoff: about 1 s, 2 s, 4 s, 8 s… between attempts, capped at 5 minutes, for a maximum of 5 attempts. While retries are pending the row reads In progress and the attempt count increases.
After the fifth failure the delivery is marked Failed and kept as a record, with the last error and the endpoint's last response.
What the statuses mean
Delivered
The destination accepted it (2xx for a webhook, a successful API call for HubSpot, the mail was handed off for emails).
No need.
In progress
Queued, being sent, or waiting for its next attempt.
Yes, automatically.
Failed
Retries exhausted. The row keeps the last error message and, for webhooks, What came back.
No. Fix the destination; the next submission or Send test will go through.
Skipped
Deliberately not performed because it could no longer apply (for example a booking sync on a form whose HubSpot destination was turned off in the meantime). Recorded once with a reason, never retried.
No.
⚠️ Note: There is no manual resend button. Failed deliveries are a log, not a queue you can replay. If a lead was lost because your endpoint was down, export the submission from Submissions or ask the respondent to submit again.
Per-integration history
Every card in the Connect tab has its own log: Webhook history, HubSpot history and Email history, each opened with View history and showing the latest 25 rows, newest first. Webhook rows include the full request and response; HubSpot rows include the action and any error the CRM returned; email rows show which notice was sent.
At the account level, the Webhooks inventory on the Connections page shows a Delivery column per form: empty when healthy, or a red {n} failed with Last failure {date}. Failures are counted per form, so a form with two webhooks shows the same count on both rows.
No duplicates on resubmit
Each delivery carries an idempotency key (submission:{submissionId}:{phase}:webhook:{index}, sent as x-forms-delivery and as id in the body). If the same session submits the same phase again, for example because the respondent went back and pressed Submit twice, pending deliveries for that phase are replaced rather than doubled, and a phase that already landed is not queued again. HubSpot is keyed by the respondent's email, so a repeat updates the same contact instead of creating a new one. On your own endpoint, store the key and ignore a request whose key you already processed.
What's next
Last updated