How to Send Email from Formcrafts with Volanea

Formcrafts can send email through its own workflow actions, but you can send email from Formcrafts with Volanea when you need your own sending domain, API-level message handling, and a clearer delivery trail. The integration is webhook-based: Formcrafts creates a new form response, then a custom webhook posts a Volanea email request.

There is no native Volanea app, marketplace listing, or one-click Formcrafts connector to install. The good news is that Formcrafts supports webhook workflow actions with custom HTTP methods, request bodies, and headers, which is exactly what a direct REST email integration needs.

This guide shows the direct route first: Formcrafts calls Volanea’s POST /v1/send endpoint after a response is created. It also explains when a small middleware endpoint is the safer architecture, how to keep the Volanea secret key out of browser-visible code, and how to avoid duplicate confirmation emails when a webhook is retried.

What triggers an email in Formcrafts?

The concrete Formcrafts event is a new form response. When a respondent submits a form, Formcrafts creates that response and runs any matching workflows. A workflow without conditions runs every time the form is submitted; add conditions when only particular responses should create an email.

That distinction matters. The trigger is not a page view, a field edit, or a partial form interaction. It is the completed submission that results in a new response. Formcrafts then sends the response data to the configured webhook URL in real time.

A practical flow looks like this:

1. A visitor submits a Formcrafts form.
2. Formcrafts creates a response and evaluates workflow conditions.
3. The workflow’s custom webhook action builds an HTTP request from form-field references.
4. The webhook posts the request to Volanea’s email endpoint.
5. Volanea validates and queues the message for sending.
6. Delivery, bounce, complaint, or suppression outcomes happen after acceptance and should be monitored separately from the initial webhook result.

For example, a request form can send a submission receipt to the respondent, an inquiry form can send an acknowledgement, or an application form can send the next-step email only when the applicant selects a qualifying option.

Choose direct webhook delivery or middleware

Formcrafts offers standard webhooks that send its predefined response payload and custom webhooks that let you control the method, headers, and body. Because Volanea accepts a JSON REST request, a custom webhook is the direct integration path.

Use a direct Formcrafts-to-Volanea webhook when the email is straightforward: one response produces one message, the recipient is a field in the form, and your team can appropriately restrict access to the workflow configuration.

Use middleware when you need stronger control over secrets, recipient selection, validation, branching, attachments, or logging. In that model, Formcrafts sends its standard JSON webhook payload to your serverless function or application endpoint. Your code validates it, deduplicates the response, and then calls Volanea.

Direct webhook is a good fit when

• The recipient is the form’s Email field.
• The message subject and content can be safely composed from known form fields.
• The sender is a verified address you control.
• The workflow editor is restricted to trusted administrators.
• A stable response ID can be used for the Volanea Idempotency-Key.
• You do not need to transform complex table, file, or multi-select values before emailing.

Middleware is a better fit when

• A secret key must never be stored in a third-party workflow configuration.
• The recipient should be chosen from a database or CRM rather than supplied by the submitter.
• The form has file uploads and you need to fetch, scan, transform, or attach them.
• You need to escape user-entered HTML before inserting it into a message.
• Different fields or webhook features are unavailable in your Formcrafts subscription or configured differently between environments.
• You need a durable audit log, queue, rate limit, fraud check, or approval step before sending.

Direct delivery is not inherently wrong. It is simply less programmable. Treat the custom webhook as configuration for a narrowly scoped transactional message, not as a substitute for an application backend.

Prepare Volanea before connecting Formcrafts

Before creating the Formcrafts workflow, set up the sender identity in Volanea. The from address in the request must use a domain that has been verified in Volanea. An unverified sender should be treated as a configuration failure, not something to solve by changing the form’s visible reply address.

Choose a sender such as forms@example.com or hello@example.com, then use a separate replyTo address if replies should reach a sales, support, or operations inbox. Keep the sender stable across confirmation emails. Changing sender identities without a reason makes it harder to trace problems and can confuse respondents.

Create a Volanea secret API key for this workflow. Volanea secret keys use the sk_ form; use a test key in a non-production form where available, and use a live key only for the published production workflow. Record the key in your password manager before leaving the key-creation screen.

You will need these values:

• Volanea API endpoint: https://api.volanea.com/v1/send
• HTTP method: POST
• Authorization header: Authorization: Bearer sk_...
• Content type: application/json
• Verified from address: for example, forms@example.com
• Formcrafts recipient field: for example, Email
• Formcrafts response identifier: used to create a stable idempotency key

For endpoint details, payload options, and current API behavior, keep the email API reference and setup guides nearby while you configure and test the workflow.

The real Formcrafts webhook payload

Formcrafts standard JSON webhooks send metadata about the response and a response_data object keyed by the form’s field labels. The following shape is representative of the documented Formcrafts JSON format, using a contact form as an example:

{
  "response_id": "1234",
  "created_at": "2024-02-23T20:12:30.081833+00:00",
  "form_id": "abcd1234",
  "form_name": "Contact us",
  "workspace_id": "e132bf87",
  "timezone": "America/Toronto",
  "page_url": "https://app.formcrafts.com/abcd1234?test=true",
  "test": true,
  "workflow_data": [],
  "response_data": {
    "Name": "Jack",
    "Email": "jack@example.com",
    "Phone": "+16479173435",
    "Message": "I would like a product demo.",
    "Topic": [
      {
        "label": "Sales",
        "value": "sales"
      }
    ]
  }
}

Two details are easy to overlook. First, response_data keys are based on the labels in your own form. If your form calls the email field Work email, then the payload key is Work email, not email. Second, values are not always strings. Multiple-choice, dropdown, slider, table, and file fields can be arrays or objects.

That is why it is worth starting with a minimal form containing Name, Email, and Message. Once the basic email works, add conditional fields and structured field types deliberately rather than assuming every value can be inserted into an email as plain text.

Configure the custom Formcrafts webhook

In the form editor, open Workflows, create a workflow or edit the workflow that should run after submission, and add the webhook action. Formcrafts documents custom webhooks as the option that gives you control over the HTTP method, body, and headers.

Set a condition if not every response deserves the same email. For instance, a demo-request form might send only when the Email field is present, while an application form may send a different email when a hidden application_status value is received.

Use the @ field-reference picker in the Formcrafts editor to insert your fields. The example below uses a form whose fields are labelled exactly Name, Email, and Message. If your labels differ, insert the matching references from Formcrafts rather than typing an assumed field name.

Direct custom webhook configuration

Configure the custom webhook with the following values. Replace the sender, reply address, and API key with your own production values.

Webhook URL
https://api.volanea.com/v1/send

HTTP method
POST

Headers
Content-Type: application/json
Authorization: Bearer sk_live_replace_with_your_volanea_secret_key
Idempotency-Key: formcrafts-response-@Response ID

Body
{
  "from": {
    "email": "forms@example.com",
    "name": "Example Co"
  },
  "to": "@Email",
  "replyTo": "support@example.com",
  "content": {
    "subject": "We received your request, @Name",
    "html": "<p>Hi @Name,</p><p>Thanks for contacting Example Co. We received your message and will reply soon.</p><p><strong>Your message:</strong></p><p>@Message</p>",
    "text": "Hi @Name,\n\nThanks for contacting Example Co. We received your message and will reply soon.\n\nYour message:\n@Message"
  },
  "metadata": {
    "source": "formcrafts",
    "formcrafts_response_id": "@Response ID",
    "formcrafts_form": "Contact us"
  }
}

This maps Formcrafts fields into a Volanea send request as follows:

The response ID is the most important mapping that is not visible to the respondent. It is the identity of the submission, not the identity of the delivery attempt. If Formcrafts sends the same workflow call again, the request must use the same idempotency key.

Keep user input out of HTML where possible

The direct body above is useful for a simple acknowledgement, but it demonstrates an important limitation: @Message is user-controlled content placed in HTML. A message containing HTML characters, malformed markup, or hostile content can render unexpectedly if the workflow does not escape it before substitution.

For a basic confirmation, prefer a short fixed HTML body that does not echo the submitted message. Send the detailed request to your internal team through a separate, middleware-generated notification instead. If you need to include arbitrary user text in HTML, use middleware that HTML-escapes it before calling Volanea.

You should still provide a plain-text version. Plain text is useful for recipients who prefer text-only email and gives you a readable fallback if the HTML message does not render as expected.

Where the Volanea API key belongs

In a direct setup, the Volanea API key is entered in the custom webhook’s Authorization header inside the Formcrafts workflow configuration. It is sent by Formcrafts’ server when it performs the webhook request; it must never be placed in the form embed snippet, browser JavaScript, a hidden field, a query parameter, or any client-visible configuration.

A hidden field is not secret storage. Visitors can inspect browser requests, modify hidden values, and read form markup. Similarly, never make the Volanea key a field reference or allow a respondent to influence the Authorization, from, or replyTo values.

Access control is the remaining concern. Anyone who can edit or view the workflow configuration may be able to change a destination or view the secret entered there. Limit Formcrafts form-editor access to trusted administrators, rotate the key when access changes, and revoke it immediately if you suspect exposure.

If that is not strong enough for your environment, use middleware instead. Store VOLANEA_API_KEY in your cloud provider’s server-side environment-variable or secrets system. Formcrafts then sends only the response data to your endpoint; your endpoint adds the Volanea Authorization header after validating the request.

Middleware example for high-control implementations

The following JavaScript example illustrates the server-side pattern. Configure a standard JSON Formcrafts webhook to post to https://your-app.example.com/webhooks/formcrafts, then store the Volanea key only in the server environment.

export async function POST(request) {
  const payload = await request.json();

  const responseId = payload.response_id;
  const email = payload.response_data?.Email;
  const name = payload.response_data?.Name || "there";

  if (!responseId || !email) {
    return Response.json({ error: "Missing response_id or Email" }, { status: 400 });
  }

  // In production, verify the Formcrafts request signature before this point,
  // then make this insert unique on responseId in your database.
  const alreadyProcessed = await hasProcessedFormcraftsResponse(responseId);
  if (alreadyProcessed) {
    return Response.json({ ok: true, duplicate: true }, { status: 200 });
  }

  const volaneaResponse = await fetch("https://api.volanea.com/v1/send", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": `formcrafts-response-${responseId}`
    },
    body: JSON.stringify({
      from: {
        email: "forms@example.com",
        name: "Example Co"
      },
      to: email,
      replyTo: "support@example.com",
      content: {
        subject: `We received your request, ${name}`,
        html: `<p>Hi ${escapeHtml(name)},</p><p>Thanks for contacting Example Co. We will reply soon.</p>`,
        text: `Hi ${name},\n\nThanks for contacting Example Co. We will reply soon.`
      },
      metadata: {
        source: "formcrafts",
        formcrafts_response_id: responseId,
        formcrafts_form_id: payload.form_id
      }
    })
  });

  const result = await volaneaResponse.json();
  if (!volaneaResponse.ok) {
    return Response.json({ error: "Volanea send failed", result }, { status: 502 });
  }

  await markFormcraftsResponseProcessed(responseId, result);
  return Response.json({ ok: true, result }, { status: 200 });
}

The omitted escapeHtml, hasProcessedFormcraftsResponse, and markFormcraftsResponseProcessed functions are deliberate: each application should use its own durable database or queue rather than an in-memory map. The structural point is to claim the response_id atomically before sending, retain the Volanea result, and return a quick response to Formcrafts.

Idempotency prevents duplicate confirmation emails

A webhook is an HTTP request across two systems. That means Formcrafts may not know whether Volanea accepted a send when a connection fails or the response is delayed. Retrying is sensible, but a naïve retry could create a second confirmation email.

Volanea supports the Idempotency-Key request header for safe retries. Give each logical form-response email a stable, unique value. formcrafts-response-@Response ID is a good direct-workflow pattern because every attempt for one response uses the same key, while two different form responses use different keys.

Do not put a timestamp, random UUID, or retry counter in that header when the email represents a single form submission. Those values change on every attempt and turn a retry into a new send.

For a middleware design, implement two layers:

1. Application-level deduplication: persist the Formcrafts response_id in a database with a unique constraint before sending.
2. Provider-level idempotency: send the same response-based key to Volanea for every retry of that one message.

The database record protects you across queues, deployments, and workers. The Volanea header protects the outbound send request itself. Together, they make the integration more robust than relying on either service alone.

When this breaks

A useful integration assumes that failure is normal: fields can be blank, external services can time out, workflow settings can change, and an accepted email is not the same as a delivered email. The following failure modes are specific to the Formcrafts-to-Volanea hop.

Formcrafts times out before it sees a response

Formcrafts documents a 30-second webhook timeout. If the target does not respond within that window, Formcrafts marks the webhook as failed. A direct Volanea request should normally complete quickly, but a network problem, edge outage, or middleware function that performs too much work can still hit the limit.

What to do: if you use middleware, verify the request, save or enqueue the response, and return a 2xx response promptly. Move slow enrichment, PDF generation, CRM lookups, or attachment processing into background work. Inspect Formcrafts workflow logs to see the status and details of failed actions.

A retry causes duplicate sends

A failed or timed-out webhook delivery is ambiguous: Volanea might have accepted the email even though Formcrafts did not receive the response. If the workflow is retried manually or a delivery is repeated, an integration without idempotency can send another message.

What to do: use Idempotency-Key: formcrafts-response-@Response ID for direct delivery. In middleware, use the same header plus a database-level unique record keyed on response_id. Never generate a new retry key for a submission that already has one.

Form fields are missing or shaped differently

Conditional fields may be absent when a respondent does not see them. A field can be renamed after the workflow is built. Structured fields such as multiple-choice, dropdown, tables, and file uploads can appear as objects or arrays instead of text. In addition, available Formcrafts workflow or webhook capabilities can differ by subscription and account configuration.

What to do: test with every branch of your conditional logic and inspect the actual standard JSON payload before writing mappings. Keep the direct email body limited to simple required fields. When a field may be missing, do not make it the sole source of a required to recipient or subject. If the necessary custom webhook capability is not available in your plan, send the standard payload to supported middleware or use an automation platform as an intermediary rather than pretending that the direct configuration exists.

The email is accepted but the respondent never receives it

A successful Volanea API response means the request was accepted or queued; it is not final proof of mailbox delivery. A recipient can be suppressed, unsubscribed, bounced, or skipped for account or reputation reasons after the Formcrafts workflow has completed.

What to do: use Volanea delivery events and message records for operational monitoring. For business-critical forms, alert the team on bounces or complaints and provide an alternative contact path on the confirmation page. Do not make a form’s success screen promise that an email was delivered.

The sender is rejected

A common configuration error is setting from.email to an address on a domain that has not been verified in Volanea. Another is setting the from address from a form field, which creates spoofing and deliverability problems.

What to do: keep from.email static and verified. Put the respondent’s email in to for an autoresponder or in replyTo only when you are sending an internal notification and have validated the address. Never let a visitor supply the sender identity.

Message content renders badly or exposes untrusted input

Rich HTML email is unforgiving. Quotes, angle brackets, long pasted text, and user-entered URLs can produce malformed HTML or content you did not intend to render. This is especially likely in a direct custom-webhook body where the form workflow substitutes raw field references.

What to do: keep direct confirmation messages short and fixed. For detailed submissions, use text content or a middleware service that escapes fields and applies a tested HTML template. Send a plain-text version alongside HTML.

Test the workflow before publishing

Build confidence with a controlled test sequence rather than publishing the form and hoping the first real respondent becomes the integration test.

1. Create a test response using a real inbox you control.
2. Confirm the workflow ran in Formcrafts workflow logs.
3. Check that the API request used the expected recipient and sender.
4. Confirm that the email subject and personalization match the submitted fields.
5. Submit the exact same scenario again only if it produces a different Formcrafts response ID; otherwise, you are testing idempotency rather than a new message.
6. Test empty optional fields, conditional branches, long names, punctuation, and a message containing <, >, quotes, and line breaks.
7. Check the Volanea message outcome after acceptance, not just the Formcrafts workflow status.

Use a separate test form or clearly marked test values where possible. Formcrafts includes a test flag in its standard webhook data, which is useful in middleware for routing test activity to a safe inbox rather than emailing customers.

A good operational practice is to add source: formcrafts and the response ID to Volanea metadata. When someone asks why they received an email, those fields let you connect the message back to the originating form response without searching through every workflow manually.

Design messages for the form journey

The easiest message to automate is not always the most useful one. A form confirmation should answer the respondent’s immediate question: did you receive this, what happens next, and how can I correct an error or get help?

For a lead or contact form, use a subject such as “We received your request” rather than a sales-heavy subject line. State a realistic follow-up expectation only if your team can honor it. For example, “Our team will reply within one business day” is better than “We’ll be in touch soon” if that is the actual process.

For an application, booking, or payment-related form, include a response reference in the body or link to a secure status page. Do not email sensitive answers, payment data, or uploaded-document links unless your privacy and access controls explicitly support that workflow.

Keep the roles separated:

• The Formcrafts form collects the response.
• The workflow decides whether an email action should happen.
• Volanea provides the authenticated transactional sending endpoint.
• Your team owns the sender identity, reply inbox, message content, and follow-up process.

That separation makes it easier to change one component without breaking the entire submission flow.

Alternatives when a direct webhook is not appropriate

If direct Formcrafts webhooks are not available in your account, or the security model does not meet your requirements, use an intermediary instead of exposing an API key in client-side code.

A serverless function is the most flexible option. It can receive a standard Formcrafts JSON webhook, validate and normalize fields, send to Volanea, and return a fast success response. It also gives you a reliable place to verify signatures, attach observability, rotate secrets, and create a data-retention policy.

Automation platforms can work for simpler non-critical workflows. Formcrafts supports Zapier, and Formcrafts is also available in Make. These tools can receive the form submission and call an HTTP endpoint, but evaluate the operational trade-off carefully: the payload now passes through another service, retries may follow a different model, and advanced data shaping can become difficult to audit.

For confirmation emails that require no custom sending infrastructure, Formcrafts also has an email workflow action for notifications and autoresponders. Use that route when the built-in action meets the requirement. Use Volanea when you specifically need an API-controlled sender, your own email infrastructure, idempotency, delivery monitoring, or a broader application email architecture.

Conclusion

To send email from Formcrafts with Volanea, use a Formcrafts workflow triggered by a new form response and configure a custom webhook that posts JSON to https://api.volanea.com/v1/send. Map Formcrafts field references into the Volanea recipient and content fields, keep the sender static and verified, and include the Formcrafts response ID in a stable Idempotency-Key.

The direct webhook approach is effective for simple acknowledgements and transactional confirmations. For untrusted HTML, complex field structures, file uploads, high-security secrets, or business-critical delivery flows, put a small middleware endpoint between Formcrafts and Volanea. Either way, test every conditional branch, inspect workflow logs, and treat an accepted send as the start of delivery tracking—not the final outcome.

FAQ

Does Formcrafts have a native Volanea integration?

No. Formcrafts does not provide a native Volanea app or marketplace installation flow. The supported direct approach is a Formcrafts custom webhook that calls Volanea’s REST API.

What exactly triggers the Volanea email?

A new form response triggers the Formcrafts workflow after a respondent submits the form. Workflow conditions can restrict that trigger to responses that match specific field values.

Where should I store the Volanea API key?

For a direct integration, enter it in the Formcrafts custom webhook’s server-side Authorization header and restrict workflow-editor access. Never put it in browser JavaScript, hidden fields, embed code, or a public configuration file. Use middleware and an environment secret if you need stronger isolation.

How do I prevent duplicate emails after a retry?

Set Volanea’s Idempotency-Key to a stable value based on the Formcrafts response ID, such as formcrafts-response-@Response ID. If you use middleware, also store processed response IDs in a database with a unique constraint.

Why did Formcrafts show the workflow as successful but the email was not delivered?

The workflow can be successful because Volanea accepted the request. Delivery may still fail later because of a bounce, suppression, unsubscribe status, or other recipient-level outcome. Check Volanea delivery events and message records for the final status.