Webhook actions
See what happened next.
Configure signed HTTP delivery and understand its recorded outcomes.
Webhooks are optional
Your inbox can be the only destination for a form’s submissions. Add an action only when accepted submissions should be sent to another system. Configure your destination and signing secret in the form draft, then publish the version.
Destination requirements
Webhook destinations must use HTTPS on port 443. Local, private, and reserved network destinations are blocked. Redirects are not followed. Destination checks are applied to the resolved address, and the connection is pinned to an allowed address.
Versioned configuration
Accepted submissions keep the published form version that was active when they arrived. Later changes to a draft or a new publication do not silently replace the destination or rules for existing work.
An optional field-equals condition can skip an action when the submitted value does not match. Plan action limits apply when saving and publishing configuration. If a plan changes and the published form exceeds its action allowance, new submissions are rejected until you reduce the actions and republish. Already accepted work keeps its original configuration.
Read the outcome precisely
| Outcome | Meaning |
|---|---|
| Queued | Work is stored and waiting for a worker or its next attempt. |
| Running | A worker has claimed the action. |
| Succeeded | The configured destination returned a successful HTTP status. |
| Failed | The attempt ended unsuccessfully and is not currently scheduled to continue. |
| Outcome unknown | The request may have produced an effect at the destination, but completion could not be established safely. |
| Skipped | The configured condition or action state did not permit delivery. |
Retries and replay
Only mark an action retry-safe if the receiving system actually honors the stable idempotency key supplied with delivery. Sending a key alone does not make a destination idempotent. Verify the destination’s behavior before enabling retry-safe processing. Safe delivery allows up to five attempts, with retry delays of 60, 300, 900, and 3,600 seconds.
For an uncertain, non-idempotent outcome, inspect the receiving system before taking action. Automatic retries and replay are blocked for that unknown outcome. A repeated payment, message, or record creation may be harmful even when Form Bastion did not receive a successful response. Eligible failed actions can be replayed using their original versioned settings.
Request signing
Outgoing webhook requests are signed with the action secret. X-FormBastion-Timestamp is the Unix timestamp. X-FormBastion-Signature is v1= followed by the hexadecimal HMAC-SHA256 of timestamp + "." + exact_request_body, using that secret. Compare signatures in constant time, enforce a suitable timestamp tolerance on the receiver, and deduplicate the delivery key before producing an effect.
Idempotency-Key and X-FormBastion-Delivery carry the same stable delivery key across retries. The JSON event is submission.received, with an id, created_at, and a submission object containing receipt_id, form_id, source_id, fields, and attachments. Attachment entries include id, name, mime, bytes, and scan_status; file bytes and public download URLs are not sent.
Processing schedule
Actions run through bounded worker jobs. The platform’s Operations page reports job execution, and the public status page shows a limited worker freshness signal. A queued action does not imply that a worker is currently running.