How to Send Email From Squarespace With Volanea

Send email from Squarespace without exposing an email API key by treating Squarespace as the event source—not the email-sending runtime. The dependable path is a Squarespace form submission, Zapier as the relay, and a small server-side endpoint that calls Volanea’s REST API.

Squarespace does not provide a native Volanea extension, marketplace app, or general-purpose server-side scripting environment where you can safely run an authenticated fetch() call. It does, however, support Zapier as a form-storage integration for supported form types. That makes the practical architecture straightforward:

1. A visitor submits a Squarespace form.
2. The Squarespace Forms New Form Submission trigger starts a Zap.
3. Zapier posts a deliberately shaped JSON payload to your serverless endpoint.
4. Your endpoint validates and deduplicates the event, then calls POST /v1/send at Volanea.
5. Volanea queues the transactional message using your verified sending domain.

This guide uses a contact or quote-request form as the example. The same pattern works for a newsletter confirmation, consultation request, downloadable-resource delivery, internal lead alert, or any workflow where a form submission should result in an email.

The Squarespace capability to use: form submissions through Zapier

The concrete Squarespace trigger is New Form Submission in the Squarespace Forms app on Zapier. It fires when a visitor submits a selected form block, newsletter block, or cover page form that is connected to Zapier storage. It is an instant trigger, not a scheduled polling workflow.

That scope matters. Do not build this around an assumed “Squarespace outbound webhook” setting: Squarespace’s standard form configuration exposes storage destinations such as email, Google Drive, mailing lists, and Zapier. It does not give a normal form block a generic webhook URL field where you can paste a Volanea endpoint. Likewise, client-side code injection is the wrong place for an email-secret workflow because page visitors can inspect browser-delivered JavaScript and network requests.

For this integration, the event is therefore:

Squarespace Forms → New Form Submission → Zapier → your secure relay → Volanea

Squarespace supports the Zapier form-storage integration on Core, Plus, Advanced, Business, Commerce Basic, and Commerce Advanced plans. Only form blocks, newsletter blocks, and cover page forms can use it. Do not substitute an add-to-cart form, a custom checkout form, or another commerce-specific form and expect it to appear in the Squarespace Forms trigger selector.

Why a relay is better than attempting a browser API call

A relay gives you four controls that a direct browser request cannot provide:

• Secret storage. The Volanea sk_... secret stays in a server-side secret store.
• Validation. You can reject a missing or malformed email address before sending.
• Idempotency. You can convert a replayed automation event into one logical email send.
• Observability. You can log a safe event identifier, status code, and Volanea email ID without recording sensitive message content unnecessarily.

It also gives you a stable boundary between a no-code site form and a developer-facing email API. If you later replace Zapier, redesign the form, or add CRM steps, the Volanea send logic can remain unchanged.

Before you build: prepare the Squarespace form and Volanea domain

Start with a form that collects only the fields you need. A simple contact form might include these fields:

• Name — text field
• Email — email field
• Topic — dropdown field
• Message — paragraph field
• Consent — checkbox, if you will use the address beyond the immediate service request

Set the form’s Form Name to something unambiguous, such as Contact request. Zapier uses the form selection during trigger setup, and a precise name makes the correct source easier to identify later. Avoid changing field labels casually after the workflow is live; Zapier maps values by the form data it receives, and renamed labels can break downstream mappings.

In Volanea, add and verify the domain you will use in the visible sender address, for example hello@example.com. Domain verification is not just an administrative checkbox. It establishes the DNS configuration Volanea needs to authenticate mail and protects recipients from seeing a send that appears to come from an unverified or misaligned domain.

Use a sender address that matches the user’s expectation. For a contact-form acknowledgement, hello@yourdomain.com or support@yourdomain.com is sensible. Do not put the form submitter’s email address in from; doing so impersonates the visitor and risks SPF/DMARC alignment problems. Put the visitor in replyTo instead, so a member of your team can reply naturally.

If you are estimating automation and email volume before launch, review transactional email pricing rather than treating all form messages as free or unlimited. The email count may include one acknowledgement to the visitor and one internal alert to your team for every submitted form.

Build the Squarespace-to-Zapier trigger

The first configuration occurs in Squarespace. Add or open the form block, then connect its storage to Zapier. Squarespace requires at least one storage option for a form to accept submissions, so it is reasonable to retain a second destination—such as an email inbox or Google Drive—as an operational backup. A backup is useful during setup, but it does not replace testing the Zap.

Configure Zapier storage in Squarespace

In the form block editor, open the storage settings and add Zapier as the storage destination. Squarespace will prompt you to connect the Zapier account and select or create a Zap. The exact navigation can vary slightly by Squarespace version and editor context, but the important result is that the form is explicitly connected to Zapier storage.

Do not assume merely connecting a Squarespace account inside Zapier is enough. The selected Squarespace form also needs Zapier storage enabled in Squarespace. Otherwise, your Zap may authenticate successfully yet receive no submissions.

Create the Zap trigger

In Zapier, create a new Zap and choose:

• App: Squarespace Forms
• Trigger event: New Form Submission
• Account: the Squarespace Forms connection created with a Forms-permission API key
• Form: Contact request or the name you gave your form

Zapier’s Squarespace Forms connection requires a Squarespace API key with Forms permission. That Squarespace key is different from the Volanea key. It authorizes Zapier to read the form event; it cannot authorize email sends through Volanea.

Submit a real test entry through the published site, not just a hypothetical field list in the editor. Use a disposable address you control and include a distinctive message such as Zapier mapping test 2026-09-24. The test event is how you confirm the actual labels and values reaching Zapier.

Understand the payload: Squarespace fields are form-defined

There is no single fixed public JSON webhook payload that Squarespace posts directly to Volanea, because this integration does not use a direct Squarespace webhook. Squarespace sends the form submission into its Zapier integration, and Zapier presents fields based on the specific form that submitted the event.

That distinction prevents a common error: writing code that expects a generic object like payload.customer.email when the actual available Zapier field may be labelled simply Email, or when your form uses Work email instead. Squarespace form field names are configured by you, so they are not a durable API schema unless you make them one.

For the form described above, the Zapier trigger data will conceptually contain form-specific values like this:

{
  "formName": "Contact request",
  "submissionId": "a-stable-id-if-provided-by-the-trigger",
  "Name": "Avery Morgan",
  "Email": "avery@example.net",
  "Topic": "Project inquiry",
  "Message": "Could we discuss a website redesign in October?",
  "Consent": "Yes"
}

Treat that example as a mapping model, not a promise that every Squarespace form includes those exact wrapper keys. The reliable fields are the fields you deliberately place on the form and then select from the Zapier test sample. If a label changes from Email to Email address, revisit every mapped action.

The clean solution is to have Zapier construct a small, stable relay payload. Your server does not need to know Squarespace’s form-editor labels forever; it only needs your relay contract.

Create a secure Zapier-to-server relay

Add a Webhooks by Zapier action after the Squarespace Forms trigger. Use a POST request to an HTTPS endpoint you control, such as a Cloudflare Worker, Vercel Function, AWS Lambda behind an API gateway, or an application route on your existing backend.

Choose a relay endpoint instead of sending from Zapier directly for a key reason: the Volanea secret should live in a proper server-side secret store. A Zap configuration is not browser-visible, but using a dedicated backend gives you safer rotation, validation, duplicate handling, and an audit point. It also avoids tying the deliverability-critical send implementation to a visual workflow editor.

Set the Zapier webhook’s request body to JSON and map the sample fields into this exact payload shape:

{
  "eventId": "{{Squarespace Forms submission identifier}}",
  "formName": "{{Squarespace Forms form name}}",
  "submittedAt": "{{Squarespace Forms submission timestamp}}",
  "name": "{{Squarespace Forms Name}}",
  "email": "{{Squarespace Forms Email}}",
  "topic": "{{Squarespace Forms Topic}}",
  "message": "{{Squarespace Forms Message}}",
  "consent": "{{Squarespace Forms Consent}}"
}

The {{...}} entries above are placeholders for fields inserted from your own Zapier trigger sample. In the Zap editor, select the matching data pills rather than typing those braces literally. If the Squarespace trigger does not expose a submission identifier, create a deterministic event key in the relay from the form name, lowercased email, submitted timestamp, and message. A true submission ID is preferable, but a stable fallback is better than no duplicate protection.

Add a second header to the relay request, for example:

X-Relay-Token: a-long-random-shared-secret

Store the same token as a server-side environment secret. This is not a replacement for end-user authentication, but it stops arbitrary internet clients from freely invoking an otherwise public endpoint. Use HTTPS only.

Where the Volanea key belongs

Store VOLANEA_API_KEY in the secret manager or environment-variable configuration for the server-side runtime. For example, use a Worker secret, a Vercel encrypted environment variable, or your cloud provider’s secret-management facility.

It must not live in any of these places:

• Squarespace Code Injection
• browser JavaScript
• page-source HTML
• a public Git repository
• a hidden form field
• a URL query string
• a client-visible site configuration object

The reason is simple: a Volanea secret key authorizes sending. Anyone who extracts it can potentially send mail under your account, consume quota, damage domain reputation, or access API capabilities available to that key. Rotate a suspected leaked key immediately and replace it in the server-side secret store.

Working code: map the relay payload to Volanea

The following Cloudflare Worker example receives the JSON body created by the Zapier webhook action and sends a form acknowledgement through Volanea. It maps fields explicitly, escapes visitor-provided text before putting it in HTML, validates the recipient, verifies the relay token, and sets Volanea’s Idempotency-Key header.

export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }

    if (request.headers.get("X-Relay-Token") !== env.SQUARESPACE_RELAY_TOKEN) {
      return new Response("Unauthorized", { status: 401 });
    }

    let submission;
    try {
      submission = await request.json();
    } catch {
      return new Response("Expected JSON", { status: 400 });
    }

    const name = String(submission.name || "there").trim();
    const email = String(submission.email || "").trim().toLowerCase();
    const topic = String(submission.topic || "General inquiry").trim();
    const message = String(submission.message || "").trim();
    const eventId = String(submission.eventId || "").trim();

    if (!/^\S+@\S+\.\S+$/.test(email)) {
      return new Response("A valid email is required", { status: 422 });
    }

    if (!eventId) {
      return new Response("eventId is required for idempotency", { status: 422 });
    }

    const escapeHtml = (value) => value.replace(/[&<>'"]/g, (character) => ({
      "&": "&amp;",
      "<": "&lt;",
      ">": "&gt;",
      "'": "&#39;",
      "\"": "&quot;"
    }[character]));

    const safeName = escapeHtml(name);
    const safeTopic = escapeHtml(topic);
    const safeMessage = escapeHtml(message).replace(/\n/g, "<br>");

    const volaneaPayload = {
      from: "Your Team <hello@yourdomain.com>",
      to: email,
      replyTo: "support@yourdomain.com",
      subject: `We received your ${topic} request`,
      text: `Hi ${name},\n\nThanks for contacting Your Team about ${topic}. We received your message and will reply soon.\n\nYour message:\n${message}`,
      html: `<p>Hi ${safeName},</p><p>Thanks for contacting Your Team about <strong>${safeTopic}</strong>. We received your message and will reply soon.</p><p><strong>Your message:</strong><br>${safeMessage || "(No message provided)"}</p>`
    };

    const response = await fetch("https://api.volanea.com/v1/send", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": `squarespace-form-${eventId}`
      },
      body: JSON.stringify(volaneaPayload)
    });

    const responseBody = await response.text();

    if (!response.ok) {
      console.error("Volanea send failed", {
        status: response.status,
        eventId,
        responseBody
      });
      return new Response("Email provider request failed", { status: 502 });
    }

    return new Response(responseBody, {
      status: 200,
      headers: { "Content-Type": "application/json" }
    });
  }
};

This is a transactional acknowledgement. For an internal notification, make a separate Volanea request with to set to a monitored team address and replyTo set to the submitter’s validated email. Do not put a visitor’s unvalidated form value into a recipient field for internal routing; otherwise, an attacker could turn the form into an email relay.

Volanea accepts a single-message request at POST /v1/send, and its Idempotency-Key header is designed for safe retry behavior. The API response indicates that the send request was accepted into the pipeline; it is not the same as a final inbox-placement guarantee. Use Volanea email records or delivery-event webhooks if your application needs to record later delivery, bounce, or complaint outcomes.

For other request fields, stored templates, batch sends, scheduling, and delivery events, use the email API reference and setup guides instead of guessing field names or copying an unrelated provider’s syntax.

Map fields deliberately, not by position

A form integration often starts with a single acknowledgement and grows into a workflow with team notifications, CRM synchronization, booking links, or customer records. Make the mapping explicit now so future changes remain safe.

Do not rely on field order. A form’s first field might be the name today and a budget selector tomorrow. Map by the named field in the Zapier sample.

Also separate transactional and marketing intent. A response that confirms receipt of a person’s own contact request is normally transactional. Adding that person to a promotional sequence is a different activity and should be governed by clear consent, appropriate list management, and your organization’s applicable privacy rules. A checkbox labelled Yes may be insufficient if its wording never clearly disclosed marketing enrollment.

When this breaks: failures in the Squarespace, Zapier, and API hop

This workflow has three separate systems, so troubleshooting starts by identifying where the event stopped. Do not immediately assume a missing email is a Volanea deliverability issue.

The form submitted, but Zapier never ran

First confirm the form is a supported type: form block, newsletter block, or cover page form. Confirm that Zapier remains enabled as a storage destination in Squarespace and that the Zap is published. Then submit the live form again with a distinctive test value and inspect the Zap’s run history.

A Squarespace Forms connection also depends on a valid Squarespace API key with Forms permission. If that key was revoked, regenerated, or created without the right permission, reconnect the account in Zapier with a new Forms key. Keep the Squarespace key separate from the Volanea secret and limit each credential to its own purpose.

Fields are missing, blank, or renamed

Field availability is tied to the selected form and its configuration. A newsletter block may only expose an email address, while a contact form may expose name, topic, and message. Unsupported Squarespace form types do not work with the Zapier form integration at all.

If a value is blank in the Zapier test data, inspect the exact form field label and field type in Squarespace. Submit a fresh test after changing the form; old samples do not prove that a changed field is available. If you rename Email to Work email, update the Zapier mapping before publishing the form change.

Use sensible defensive defaults in the relay, but do not silently send an acknowledgement without an email address. Return a 422 error from the relay for invalid input so the failed automation is visible and can be replayed after correction.

A retry causes duplicate emails

Never assume an automation delivery is exactly once. A network timeout can occur after your relay successfully submits the message to Volanea but before Zapier receives the HTTP response. A system may then retry the action, and a duplicate acknowledgement can result unless your API call is idempotent.

The Worker code uses Idempotency-Key: squarespace-form-<eventId>. When the same logical submission is replayed with the same event ID, Volanea can recognize it as the same send request rather than treating it as a new email. Keep this key deterministic for one submission and different for every new submission.

If the trigger does not provide a dependable submission ID, create one from a canonicalized combination of fields and save it in a durable store before sending. For example, hash the form name, email, timestamp, and message. Do not use Date.now() or a random UUID generated during each retry; those values defeat deduplication because every repeat looks new.

Zapier reports a webhook timeout

Your relay should do only the work needed to validate, deduplicate, and call Volanea. Avoid slow database queries, large attachment generation, external enrichment calls, or image rendering before returning a response. Those activities can push the webhook action beyond its request timeout and lead to retries.

If you need heavier processing, accept the validated event quickly, store it in a queue or database with a unique event ID, and return a successful response. A background worker can then build the final email. The queue consumer should preserve the same idempotency key when it calls Volanea.

Volanea returns authentication or sender errors

An authentication failure normally means the server-side VOLANEA_API_KEY is missing, incorrect, expired, or accidentally pasted with whitespace. Log only that the secret is present and a masked prefix if required; never write the full key into logs.

A sender-related failure often points to an unverified domain or a from address that does not belong to the verified domain. Keep the visible sender stable and confirm the required DNS records for the sending domain are verified before testing the full Squarespace workflow.

The API accepted the request, but the recipient did not see it

An accepted send is not proof of inbox placement. Check the address spelling, spam or promotions folders, suppression status, bounce data, and delivery events. If you are testing with the same address repeatedly, inspect the exact message headers and timestamps so you do not mistake an older test email for a current result.

Avoid putting the entire form message in the subject line. Form submissions can contain unexpected characters, very long values, or hostile text. Keep the subject controlled by your application and include user input only in escaped body content.

Improve reliability and deliverability after the first send

Once the basic acknowledgement works, build a slightly more mature workflow rather than adding more unstructured Zap steps.

First, use two messages with two purposes: an acknowledgement to the visitor and a notification to your team. The acknowledgement should set expectation—such as a response window—while the internal notification should make follow-up easy. Give each message a distinct idempotency key, such as submission-123-ack and submission-123-team, so retry behavior is correct for both.

Second, use a controlled reply path. For a team alert, set replyTo to the submitter’s email after validation. For the visitor acknowledgement, use your normal support mailbox as replyTo. This preserves a clear conversational path without forging the visitor as the sender.

Third, keep a minimal audit record containing the submission event ID, form name, relay receipt time, Volanea response status, and resulting email identifier when available. Avoid storing full message content indefinitely unless your privacy policy and operational requirements justify it.

Finally, test changes as production changes. Submit the form from a real browser, verify the Squarespace confirmation behavior, inspect the Zap run, confirm the relay log, and review the received email in at least two mailbox providers. This end-to-end test catches mapping errors that an isolated API test cannot.

Alternatives and when to choose them

Squarespace Email Campaigns can send certain built-in automations, including form response automations, without Volanea. That is a reasonable option when you need a simple branded reply and the built-in automation’s trigger, sending controls, and reporting meet the requirement.

Use the Zapier-plus-relay approach when the email is part of your application logic: you need server-owned secrets, custom idempotency, precise API-level handling, an internal notification plus acknowledgement, richer validation, or a future path to CRM and backend data.

If you already operate an application backend, you may also have it consume form data from an appropriate workflow or form API integration and send through Volanea itself. The key architectural rule remains the same: calls to Volanea must originate from a trusted server-side environment, never from public Squarespace page code.

Conclusion

To send email from Squarespace with Volanea, use the event Squarespace genuinely provides: a New Form Submission delivered to Zapier from a supported form type. Then use Zapier as a controlled relay to a server-side endpoint where the Volanea API key is protected.

The integration succeeds when the boundaries are explicit. Squarespace collects the visitor’s information. Zapier transports a mapped event. Your relay validates, escapes, and deduplicates it. Volanea sends through your verified domain. That separation is more secure than exposing a key in front-end code and more reliable than assuming a form submission can never be retried.

FAQ

Can I install a Volanea plugin from the Squarespace marketplace?

No. Volanea does not provide a native Squarespace marketplace app or plugin. Use Squarespace Forms with Zapier and a secure server-side relay to call Volanea’s REST API.

What starts the email workflow in Squarespace?

The trigger is New Form Submission from the Squarespace Forms app in Zapier. It applies to a connected form block, newsletter block, or cover page form—not every Squarespace form type.

Can I put my Volanea API key in Squarespace Code Injection?

No. Code Injection is delivered to site visitors and must be treated as client-visible. Put the Volanea secret in a server-side environment secret, such as a Worker secret or serverless-function environment variable.

How do I prevent duplicate acknowledgement emails?

Pass a stable, per-submission value as Volanea’s Idempotency-Key. Use a Squarespace/Zapier submission identifier when available; otherwise generate a deterministic key from canonical submission data and persist it before sending.

Can I use this workflow for marketing emails?

Use it for transactional acknowledgements by default. For promotional mail, collect clear marketing consent, manage subscription state, and keep marketing enrollment separate from a person’s request for a service response.