Form Webhooks: Connecting Submissions to Everything Else

A webhook is the simplest useful integration: when something happens, send an HTTP request somewhere. For forms, that means every submission can reach your own systems within a second, without polling, exports, or a scheduled sync that runs at 3am and fails silently.

Most teams need one for the same handful of reasons.

When a webhook is the right tool

Use one when the destination is your own system, or a service with no prebuilt integration, or when you need to transform the data before it lands somewhere.

Do not use one when a native integration exists and does the job. A webhook is code you now own, monitor and maintain; if a first-class connection covers your case, that is strictly less work.

The most common good reasons: writing submissions into an internal database, triggering a provisioning step, notifying a channel with custom formatting, or fanning one submission out to several systems.

Verify the signature

Anything that accepts webhooks is a public endpoint. Without verification, anyone who learns the URL can post whatever they like into your systems.

Instaform signs each delivery with an HMAC over the payload using a secret you hold. Compute the same signature on receipt and reject anything that does not match, using a constant-time comparison rather than string equality. This is a few lines and it is the difference between an integration and a vulnerability.

Respond fast, process later

Return 200 as soon as you have stored the payload. Do the actual work afterwards, in a queue.

Endpoints that do their processing inline eventually hit a slow dependency, exceed the timeout, and get marked as failed — at which point you receive retries for work that already succeeded. Acknowledge receipt, then process.

Assume duplicates

Networks fail in both directions. A delivery can succeed on your side and time out on the way back, which produces a retry for something you already handled.

Make handlers idempotent: key on the submission ID and ignore anything you have already processed. This is much easier to build in from the start than to retrofit after the first duplicate charge or duplicate ticket.

Handle failure visibly

Deliveries fail. The endpoint is deploying, the third-party is down, someone rotates a credential.

Instaform retries with backoff and records consecutive failures, deactivating an endpoint that has clearly gone away rather than retrying indefinitely. What matters on your side is noticing: a webhook that has been failing for a week is a week of submissions that never reached the system that needed them.

Check the delivery status when you change anything at the receiving end. That is the moment endpoints break, and it is the moment nobody looks.

Keep the record regardless

The important property is that a failed webhook should never mean a lost submission. In Instaform the submission is stored as a Contact first and delivered second, so an endpoint outage delays the integration without losing the data — you can replay once it is back.

That ordering matters more than any other design decision here. Systems that only forward, and never store, turn every integration outage into permanent data loss. See lead generation for what that stored record does afterwards, and the contact form template for a starting point.