Skip to content

Testing a Form

You can send a real test submission from a preview, before a form goes anywhere near a customer. A test submission runs the whole pipeline: the email lands in the inbox you configured, and any webhook you set up receives a delivery. Every submission that originates in a preview is marked as a test, so a test is never mistaken for a customer inquiry.

Where You Can Test a Form

Where Submit button What it tests
The editor canvas Disabled Nothing. Clicking the button selects the form component.
The form's own preview Live The draft, exactly as you last saved it.
The preview of a page or block that embeds the form Live The published form.
The storefront Live The published form, as a real customer submission.

In the canvas the button is deliberately inert, with the note "Submitting is disabled in the editor. Test submissions from the full-screen preview." beside it.

Testing the Form on Its Own

  1. Save the form. The preview shows what is saved, so the editor asks you to save first if you have unsaved changes.
  2. Open the Preview menu in the editor header and choose Open in New Tab.
  3. Fill the form in and submit it.

The preview renders your draft, and the submission is checked against that same draft, so a field you have added but not published yet is testable straight away. A form that has never been published is testable too, as long as Enable Form is on.

Testing the Form Where It Is Embedded

Preview the CMS page or block that embeds the form instead, and submit from there. That is the way to check the form in its real surroundings, with your page's layout, spacing and theme styling around it.

An embedded form always renders and validates the published version, because that is what the page itself embeds. Publish the form first, then preview the page.

What a Test Submission Does

  • The email is really sent, to the recipients set in Form Settings > Submission, with [test] in front of the subject. The prefix goes on last, so nothing in the subject can interpolate it away, and it is never translated, which keeps inbox rules simple.
  • The webhook really fires, to the Send Submissions To URL you configured. Every test delivery carries the HTTP header X-Hyva-Form-Test: 1. The JSON (with form context) format also carries "test": true in the body. The two flat formats carry the header only.
  • The customer's side behaves exactly as it will live. Your success message shows, the redirect happens, or your chosen CMS block renders in place of the form, with the same copy, the same target page and the same block.
  • Nothing is stored in the admin, just as for a live submission. The email is the record.
  • Spam protection still applies. The built-in honeypot is not rendered in a preview, so there is nothing there to trip. CAPTCHA is not skipped: if the form has Enable CAPTCHA on, solve the challenge the way a customer would. See Spam protection for how the two layers work.

Your webhook receiver gets a real delivery

A test submission is not a dry run. Anything downstream of the webhook, a CRM, a Zapier automation, a mailing list, receives the delivery and acts on it. Ask whoever owns the receiving end to check for the X-Hyva-Form-Test header and drop or quarantine those deliveries before you start testing. See Webhook deliveries for the exact marker.

A test submission is how you preview the success content

The canvas never renders the success state, so send a test submission from the full-screen preview to see the success message, or the block you picked as Success Content, as the customer gets it. A block that can't be shown falls back to the message, which a test surfaces as well. See Sending and Recipients.

When a Test Cannot Send

  • The form is disabled. With Enable Form off, submitting says "This form is no longer available." Turn the form on to test it, and remember that publishing and enabling are two separate things.
  • The form has no destination. With no recipient and no webhook, the submission succeeds and the success message shows, but nothing is sent anywhere. Previewing the form on its own warns you about this; previewing a page that embeds it does not, so check the form on its own first.
  • CAPTCHA is on but reCAPTCHA is not configured. The submission is rejected with the same generic security message a customer would get. Previewing the form on its own warns you here as well, an embedding page's preview stays silent. See Spam protection for the store-level setup.
  • The preview link was edited. Test status is worked out on the server from the preview link's signature. Change any of it and the submission is treated as an ordinary storefront submission: validated against the published form, sent unmarked. Copying an unedited preview link and submitting from it is a genuine test.

Store views and previews

A preview opened for a non-default store view still submits in the default store's scope, so anything store-specific, translated copy or a store-scoped recipient, is better checked on the storefront after publishing.