How to Send Email From OnceHub With Volanea

OnceHub can trigger email beyond its built-in notifications. This guide shows how to send email from OnceHub with Volanea by receiving a signed OnceHub booking webhook in your own server or serverless function, then making a secure REST API call to Volanea.

There is no native Volanea app, marketplace listing, or plug-in to install in OnceHub. The reliable integration is a webhook-to-server pattern: OnceHub reports a booking lifecycle event, your endpoint validates it, maps booking fields to an email, and calls Volanea from a protected runtime.

What the OnceHub-to-Volanea integration does

The most useful starting point is the Booking Scheduled webhook trigger. Once a guest schedules a meeting through a Booking Calendar, Booking Hub, Chatbot, or Routing Form, OnceHub emits a booking.scheduled event and sends an HTTP POST request to the URL configured for that webhook subscription.

Your endpoint receives the event, verifies that it came from OnceHub, and decides what to send. In most cases, that means one of two email paths:

• Send the guest a branded confirmation or preparation email that supplements the standard scheduling notification.
• Send an internal alert to a sales representative, account owner, or operations inbox with the booking details and form answers.

The second option is especially useful when you need message content that depends on your own rules. For example, you might notify a specific territory owner when the booking form’s company field is present, route a high-value inbound request to an escalation inbox, or include internal context from a CRM lookup before the email is sent.

The integration has four moving parts:

1. OnceHub webhook subscription: Configured to listen for Booking Scheduled events and deliver JSON to an HTTPS endpoint.
2. Your server-side receiver: A small API route, serverless function, or worker that validates the OnceHub signature and handles duplicate delivery safely.
3. Volanea secret key: Stored only as a server-side environment secret.
4. Volanea send call: A POST request to https://api.volanea.com/v1/send with the recipient, sender, subject, HTML, and plain-text fallback.

This is a direct integration in the sense that OnceHub posts straight to your endpoint. It is not a browser-side connection and it should not send directly from embedded OnceHub JavaScript. The webhook body can contain personally identifiable booking information, while the Volanea secret key can authorize sending. Both facts make a protected backend hop essential.

The concrete OnceHub trigger: Booking Scheduled

For a straightforward booking follow-up, choose Booking Scheduled in OnceHub’s webhook event selection. This is the event generated when a customer schedules a new booking. The corresponding event type in the delivered JSON is booking.scheduled.

A booking can originate from more than one OnceHub surface. A guest might schedule through a Booking Calendar or Booking Hub, or be scheduled after interacting with a Chatbot or Routing Form. The webhook event gives your integration one normalized place to respond, even if the booking source varies.

Do not use a generic “form submitted” assumption for this workflow. OnceHub’s booking webhook model centers on booking and conversation lifecycle events. For an appointment confirmation, booking.scheduled is the correct business event because it means a scheduled booking now exists, including its booking ID, start time, assigned owner, and form submission object.

Create the webhook in OnceHub

An administrator can create the subscription in the OnceHub application:

1. Open the gear menu in the top-right corner.
2. Choose Account Integrations.
3. Open the APIs & Webhooks tile.
4. In the Webhooks section, select Create Webhook.
5. Enter a descriptive name such as Volanea booking follow-up.
6. Enter your receiving URL, for example https://app.example.com/webhooks/oncehub.
7. Continue to the trigger selection and select Booking Scheduled.
8. Create the webhook and copy the Webhook Secret immediately.

The endpoint must use HTTPS. Treat the OnceHub Webhook Secret as a credential: store it in your deployment’s secret manager or environment configuration, not in source control, browser code, or a shared document.

OnceHub can also manage webhook subscriptions through its API, but creating the first subscription through the application interface makes it easy to verify the endpoint URL, select the exact lifecycle trigger, and retrieve the secret associated with that endpoint.

Decide what one booking should cause

Before writing code, write one sentence that defines the result of a Booking Scheduled event. For example:

When a guest schedules a 30-minute discovery call, email the guest a branded confirmation with the time, meeting location, and a reply path.

That statement settles several design questions. The guest email from data.form_submission.email is the recipient. The booking subject becomes context in the subject line. data.starting_time, data.duration_minutes, data.location_description, and data.virtual_conferencing.join_url can populate the message. The OnceHub event ID becomes an idempotency key so a delivery retry does not create a second confirmation.

If your goal is an internal alert instead, keep the same trigger but set the Volanea recipient to a controlled address such as sales@example.com. Do not automatically trust arbitrary form values as internal routing addresses.

Understand the OnceHub webhook payload before mapping fields

OnceHub sends a JSON event envelope. For a Booking Scheduled event, the outer event identifies the event and the nested data object contains a booking object. A representative payload shape looks like this:

{
  "id": "EVNT-2AB8RJY3LF",
  "object": "event",
  "creation_time": "2021-01-20T12:10:03.140Z",
  "type": "booking.scheduled",
  "api_version": "v2",
  "data": {
    "object": "booking",
    "id": "BKNG-YNMGHKQ24XV5",
    "tracking_id": "BKNG-YNMGHKQ24XV5",
    "subject": "15-minute meeting",
    "status": "scheduled",
    "creation_time": "2021-01-20T12:10:02.487Z",
    "starting_time": "2021-01-20T16:45:00.000Z",
    "last_updated_time": "2021-01-20T12:10:02.753Z",
    "duration_minutes": 15,
    "owner": {
      "id": "USR-YX0J4ANZTV",
      "first_name": "Michael",
      "last_name": "",
      "email": "michael@example.com",
      "status": "active"
    },
    "virtual_conferencing": {
      "join_url": ""
    },
    "location_description": "",
    "form_submission": {
      "name": "Carrie",
      "email": "carrie@customer.com",
      "phone": "",
      "mobile_phone": "",
      "note": "",
      "company": "",
      "guests": [],
      "custom_fields": []
    },
    "booking_calendar": {
      "id": "BKC-LDJ878496X",
      "object": "booking_calendar",
      "name": "Andrea Hartie booking calendar",
      "subject": "Meeting with Andrea Hartie",
      "url": "https://oncehub.com/andreahartie",
      "published": true
    }
  }
}

The example is a shape guide, not a license to assume every field has a value. OnceHub uses a consistent payload structure across booking event types, but fields irrelevant to a particular event can appear as null. A value such as virtual_conferencing.join_url also depends on how the booking configuration and conferencing integration are set up.

For Booking Scheduled notifications, validate the fields that are genuinely required for your email. At a minimum, a guest confirmation normally needs a syntactically valid data.form_submission.email. An email that states the meeting time should only render that time when data.starting_time is present and parseable.

Recommended field mapping

Use a deliberate mapping rather than spreading the full webhook payload directly into an HTML template.

This mapping is also an important privacy boundary. A guest confirmation should contain only information the guest should see. For example, an internal staff email can include the guest’s note and company name, but you may not want either one inserted into a generic confirmation message.

The secure architecture for sending through Volanea

The correct data flow is:

OnceHub Booking Scheduled event
        |
        | HTTPS POST + Oncehub-Signature header
        v
Your webhook endpoint
        |
        | verify HMAC, validate fields, deduplicate
        v
Volanea POST /v1/send
        |
        v
Guest or internal recipient inbox

OnceHub does not provide a place to paste a Volanea API key into the webhook subscription. The OnceHub configuration stores the destination URL and exposes a Webhook Secret used to prove the event’s origin. The Volanea API key belongs on the receiving server side, typically as an environment variable such as VOLANEA_API_KEY.

That distinction matters. A webhook is not an HTTP action builder where you can safely add a bearer token for a second service. OnceHub sends to your endpoint; your endpoint authenticates to Volanea. This lets you keep the email credential out of the OnceHub payload, out of browser-accessible JavaScript, and out of request logs.

Store three separate secrets

A production integration commonly needs these values:

• ONCEHUB_WEBHOOK_SECRET: The secret revealed when the OnceHub webhook subscription is created. Use it only to verify incoming signatures.
• VOLANEA_API_KEY: A Volanea secret key, typically beginning with sk_ or sk_test_, used only for calls from your server to the Volanea API.
• EMAIL_FROM: A verified sender address, for example Meetings <meetings@example.com>.

Keep these in deployment secrets, not in a public .env file committed to Git. On platforms with environment scopes, use a test Volanea key and a separate OnceHub webhook subscription for staging. This prevents a staging booking from sending a production-branded email to a real guest.

Your sender address must be associated with a verified sending domain in Volanea. Domain authentication and sender alignment are separate from the OnceHub connection, but they affect whether the email reaches the inbox as expected. Review the email API reference and setup guides when configuring the sending domain, API key, and message options.

Working Node.js webhook handler with field mapping

The following Express example receives the raw body, verifies the OnceHub v2 HMAC-SHA-256 signature, checks for booking.scheduled, maps the actual booking fields, and sends a Volanea transactional email.

It uses the OnceHub event ID as Volanea’s Idempotency-Key. That is critical: OnceHub retries failed webhook deliveries, and the same event must not turn into multiple guest emails.

import crypto from "node:crypto";
import express from "express";

const app = express();

// Keep raw bytes/text available: signature verification must use the original body.
app.post("/webhooks/oncehub", express.raw({ type: "application/json" }), async (req, res) => {
  const rawBody = req.body.toString("utf8");
  const signatureHeader = req.get("Oncehub-Signature");

  try {
    verifyOnceHubSignature(
      signatureHeader,
      rawBody,
      process.env.ONCEHUB_WEBHOOK_SECRET
    );
  } catch (error) {
    console.error("Rejected OnceHub webhook:", error.message);
    return res.status(401).json({ error: "Invalid webhook signature" });
  }

  let event;
  try {
    event = JSON.parse(rawBody);
  } catch {
    return res.status(400).json({ error: "Invalid JSON" });
  }

  // A single endpoint can receive multiple OnceHub event types.
  if (event.type !== "booking.scheduled") {
    return res.status(204).end();
  }

  const booking = event.data;
  const guest = booking?.form_submission;
  const recipient = guest?.email?.trim();

  if (!event.id || !recipient || !isEmail(recipient)) {
    console.error("Booking Scheduled event missing required send fields", {
      eventId: event.id,
      bookingId: booking?.id,
      recipient
    });

    // Return 2xx after recording a non-retryable data problem.
    // Otherwise OnceHub will retry the same malformed event.
    return res.status(204).end();
  }

  const guestName = escapeHtml(guest.name?.trim() || "there");
  const meetingName = escapeHtml(booking.subject?.trim() || "your meeting");
  const hostName = escapeHtml(booking.owner?.first_name?.trim() || "our team");
  const when = formatUtcDate(booking.starting_time);
  const duration = Number.isFinite(booking.duration_minutes)
    ? `${booking.duration_minutes} minutes`
    : null;
  const joinUrl = booking.virtual_conferencing?.join_url?.trim() || "";
  const location = escapeHtml(booking.location_description?.trim() || "");

  const details = [
    when ? `<p><strong>When:</strong> ${escapeHtml(when)}</p>` : "",
    duration ? `<p><strong>Duration:</strong> ${escapeHtml(duration)}</p>` : "",
    location ? `<p><strong>Location:</strong> ${location}</p>` : "",
    joinUrl
      ? `<p><a href="${escapeAttribute(joinUrl)}">Join the meeting</a></p>`
      : ""
  ].join("");

  const textDetails = [
    when && `When: ${when}`,
    duration && `Duration: ${duration}`,
    booking.location_description && `Location: ${booking.location_description}`,
    joinUrl && `Join the meeting: ${joinUrl}`
  ].filter(Boolean).join("\n");

  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": event.id
    },
    body: JSON.stringify({
      from: process.env.EMAIL_FROM,
      to: [recipient],
      subject: `Confirmed: ${booking.subject || "your meeting"}`,
      html: `
        <p>Hi ${guestName},</p>
        <p>Your ${meetingName} with ${hostName} is scheduled.</p>
        ${details}
        <p>If you need to make a change, use the scheduling link in your original booking confirmation.</p>
      `,
      text: `Hi ${guest.name?.trim() || "there"},

Your ${booking.subject || "meeting"} with ${booking.owner?.first_name || "our team"} is scheduled.

${textDetails}

If you need to make a change, use the scheduling link in your original booking confirmation.`
    })
  });

  if (!volaneaResponse.ok) {
    const errorBody = await volaneaResponse.text();
    console.error("Volanea send failed", {
      status: volaneaResponse.status,
      eventId: event.id,
      body: errorBody
    });

    // A 5xx lets OnceHub retry. The same Idempotency-Key protects against duplicates.
    return res.status(502).json({ error: "Email provider send failed" });
  }

  return res.status(202).json({ accepted: true, eventId: event.id });
});

function verifyOnceHubSignature(header, rawBody, secret) {
  if (!header || !secret) throw new Error("Missing signature or webhook secret");

  const parts = Object.fromEntries(
    header.split(",").map((part) => {
      const [key, value] = part.trim().split("=");
      return [key, value];
    })
  );

  const timestamp = parts.t;
  const signature = parts.s;
  if (!timestamp || !signature) throw new Error("Malformed Oncehub-Signature header");

  const signedPayload = `${timestamp}.${rawBody}`;
  const expected = crypto
    .createHmac("sha256", secret)
    .update(signedPayload, "utf8")
    .digest("hex");

  const actualBuffer = Buffer.from(signature, "hex");
  const expectedBuffer = Buffer.from(expected, "hex");

  if (
    actualBuffer.length !== expectedBuffer.length ||
    !crypto.timingSafeEqual(actualBuffer, expectedBuffer)
  ) {
    throw new Error("Signature mismatch");
  }
}

function formatUtcDate(value) {
  if (!value) return null;
  const date = new Date(value);
  if (Number.isNaN(date.getTime())) return null;
  return new Intl.DateTimeFormat("en-US", {
    dateStyle: "full",
    timeStyle: "short",
    timeZone: "UTC"
  }).format(date) + " UTC";
}

function isEmail(value) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value);
}

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

function escapeAttribute(value) {
  return escapeHtml(value).replace(/`/g, "&#96;");
}

app.listen(process.env.PORT || 3000);

The code deliberately returns a 2xx response for an event that is structurally valid but not eligible for a guest send, such as one without an email address. Retrying cannot manufacture a missing field. By contrast, it returns a non-2xx response when the Volanea request fails, allowing OnceHub to redeliver the event.

In a high-volume production system, improve this further by putting a queue between validation and the Volanea call. The webhook handler can validate the signature, persist the event ID, enqueue the job, and return 202 immediately. A worker then calls Volanea with the same idempotency key. That design lowers timeout risk and gives you a place to inspect failures without blocking OnceHub’s delivery attempt.

Why signature verification must use the raw request body

OnceHub signs webhook events in an Oncehub-Signature request header. The header contains a timestamp value prefixed with t= and a signature prefixed with s=. The signed value is the timestamp, a period, and the exact JSON request body:

${timestamp}.${rawJsonBody}

OnceHub calculates the signature with HMAC SHA-256 and the Webhook Secret assigned to that endpoint. Your handler must calculate the same HMAC and compare the result using a timing-safe comparison.

Do not parse JSON and then stringify the object before checking the signature. Even if the data means the same thing, JSON serialization can change whitespace or property ordering. That produces a different byte sequence and a failed signature check. Read the raw body first, verify it, and parse it only after validation succeeds.

Also consider enforcing a timestamp freshness window, such as five minutes, after verifying the HMAC. It is a useful defense against replay attempts. If you implement it, ensure server clocks are synchronized and document the expected behavior before rejecting otherwise valid events.

Customize the email without turning the webhook into a template engine

The example sends inline html and text content. That is a practical choice for one compact confirmation message because the mapping remains visible in code. As message variants grow, move the content to a Volanea stored template and send the booking values as template variables instead.

The important principle is the same in either approach: create an allowlist of fields that may appear in the message. Do not serialize event.data into an email template wholesale. Booking payloads can contain notes, phone numbers, guest lists, custom fields, and owner metadata that are not appropriate for every recipient.

Good follow-up email patterns

A Booking Scheduled event can drive several useful transactional messages:

• Guest confirmation enhancement: Add preparation instructions, a support address, a product-specific agenda, or a conference fallback link.
• Owner notification: Send the assigned OnceHub owner an internal email with the guest’s name, company, note, booking time, and booking ID.
• Team routing: Send a notification to an account queue based on a validated custom-field value or an external CRM lookup.
• Compliance or operations record: Email a controlled archive address only when your retention and consent policies allow it.
• Pre-meeting task email: Notify a coordinator when a meeting is scheduled with a specific Booking Calendar.

Avoid treating a Booking Scheduled event as marketing consent. A booking-confirmation message is transactional when it concerns the scheduled meeting. Campaign or promotional follow-up should be separated from the booking flow and should honor your consent, suppression, and regional privacy requirements.

Format time zones intentionally

OnceHub’s example booking timestamps use ISO 8601 UTC timestamps. The code above labels the rendered time as UTC rather than silently presenting it as the guest’s local time. That is safer than guessing.

For a better guest experience, determine the display time zone from a reliable source before formatting. You might use the booking configuration, a CRM profile, or a known sales territory. If no trustworthy time zone exists, retain the ISO timestamp or explicitly state UTC. A beautifully designed confirmation that names the wrong time zone is worse than a plain message with a clear one.

When this breaks: OnceHub webhook failure modes

The fragile part of this integration is not the email API alone. It is the hop from OnceHub to your receiving endpoint, plus the hop from your endpoint to Volanea. Design for the following outcomes before they become customer-facing incidents.

OnceHub retries can cause duplicate sends

OnceHub treats a non-2xx response as a failed webhook delivery and retries automatically with exponential backoff for roughly three days. If your endpoint sends the Volanea email but loses the network response before returning 2xx to OnceHub, OnceHub may deliver the same event again.

Use event.id as the Volanea Idempotency-Key, exactly as in the example. The value is stable for the event, while a new booking event receives a different event ID. Do not generate a fresh UUID on every handler execution; that defeats deduplication.

For additional protection, keep a database record keyed by the OnceHub event ID. Record the event when accepted, track Volanea’s response, and make repeated arrivals no-ops. This is useful if the email provider response is ambiguous, if you later add multiple downstream actions, or if your business logic itself has non-idempotent steps.

Slow webhook endpoints can create retry storms

A webhook endpoint that waits on slow database queries, CRM enrichment, image generation, or a long external HTTP call is more likely to time out. OnceHub sees an unsuccessful delivery and retries; meanwhile, your original work may eventually finish. That is a classic duplicate-processing situation.

Keep the webhook request path narrow:

1. Read the raw body.
2. Verify the OnceHub signature.
3. Parse and validate the event.
4. Persist or enqueue it with the event ID as the unique key.
5. Return a 2xx response promptly.
6. Process slow enrichment and email sending asynchronously.

A queue is not mandatory for a small implementation, but the discipline is. If you send synchronously, set reasonable outbound timeouts and monitor both your endpoint latency and Volanea error responses.

Fields may be null, absent, or unavailable in your configuration

Do not assume every booking contains a conference join URL, a company name, a note, a phone number, a custom field response, or even the same useful metadata across your OnceHub setup. OnceHub’s normalized webhook shape can include fields that are irrelevant to a particular event as null.

Feature availability and account configuration can also affect what you can capture and act on. Webhooks and API capabilities are advanced integration features, so verify that the OnceHub account and product setup used in production actually exposes the APIs & Webhooks area and the needed trigger. Before building message logic around a custom field, create a test booking that populates it and inspect the real payload your own subscription receives.

The correct response to a missing nonessential field is a safe fallback: omit the join button, omit a blank company line, or use a generic greeting. The correct response to a missing required recipient is to log the event and stop that guest send, not to guess an address from a name or forward personal data to an uncontrolled mailbox.

Signature failures usually come from middleware order

If every OnceHub delivery returns 401, check whether your framework parsed the request body before the signature code ran. OnceHub’s HMAC verification requires the raw JSON body. Configure the webhook route to receive raw bytes before global JSON middleware, or use the framework’s documented raw-body option for that route.

Also confirm that the header name is read case-insensitively by your platform and that the secret belongs to this exact webhook endpoint. Each OnceHub endpoint has its own secret. Rotating or recreating the subscription means updating the server-side ONCEHUB_WEBHOOK_SECRET as part of the same deployment change.

A 401 or 4xx from Volanea is not a retry problem

If Volanea returns an authentication or validation error, repeating the request is unlikely to fix it. Check the secret key, Authorization: Bearer header, verified from address, recipient value, and JSON shape. Log the response body carefully, but redact authorization values and personal data from centralized logs.

If Volanea returns a transient server or network failure, retrying can be appropriate. Keep the Idempotency-Key unchanged. That is what lets a transport retry remain safe when the first request might already have been accepted.

Test the workflow before enabling it for real bookings

Start with a test endpoint that records headers and body content. OnceHub recommends using a request-testing service to confirm that the subscription is configured and sending the expected event. This lets you inspect the actual event type, signature header, booking data, and nullable fields before you connect the sender.

A practical test plan is:

1. Create the OnceHub webhook with only Booking Scheduled enabled.
2. Point it at a test receiver and schedule a test booking.
3. Confirm the event type is booking.scheduled and preserve one scrubbed sample payload.
4. Configure the production-style handler with a Volanea test key or a safe test recipient.
5. Confirm signature validation succeeds before parsing or sending.
6. Verify the field mapping and plain-text fallback in a real inbox.
7. Replay the same event in a controlled environment and confirm idempotency prevents a second message.
8. Force a temporary Volanea failure and confirm your return status produces the intended OnceHub retry behavior.

Do not test by pointing a new webhook straight at a live guest list. Use a Booking Calendar reserved for internal testing or control the recipient mapping until the workflow is proven.

Direct webhook versus automation middleware

Because OnceHub supports outbound webhook delivery, a direct server-side endpoint is the best option when you need signature verification, precise field handling, idempotency, custom HTML, or control over the Volanea secret key.

OnceHub also documents automation integrations such as Zapier and Make. Those can be useful when you do not operate a backend. In that route, OnceHub triggers the automation platform, and the platform’s HTTP request module calls Volanea.

The trade-off is security and reliability control. The Volanea secret key must still be stored in the automation platform’s private connection or credential vault, never in a front-end URL or client-visible configuration. You also need to confirm that the automation platform can preserve or implement an idempotency strategy; a simple “new booking, make HTTP request” scenario may otherwise duplicate messages when runs are replayed or retried.

For a business-critical booking confirmation, prefer the direct webhook handler. It gives you control over signature verification, durable deduplication, logging, retries, recipient validation, and sender policy. For a low-risk internal notification, middleware can be a reasonable operational shortcut if its credential storage and replay behavior meet your requirements.

Operational checklist for production

Before relying on this integration, confirm each item below:

• OnceHub webhook is configured for Booking Scheduled, not an unrelated lifecycle event.
• Webhook URL is HTTPS and points to the intended production environment.
• The OnceHub Webhook Secret is copied and stored server-side.
• The handler verifies Oncehub-Signature against the raw request body.
• The handler accepts only expected event types.
• Guest recipient email is validated before calling Volanea.
• Guest-visible HTML is escaped and does not expose internal notes by accident.
• The Volanea key is an environment secret, not part of OnceHub configuration or browser code.
• The from address is verified and aligned with your sending domain.
• The OnceHub event ID is sent as Idempotency-Key.
• Logs include event and booking IDs but redact email bodies, secrets, and authorization headers.
• Monitoring alerts on signature failures, Volanea failures, non-2xx webhook responses, and growing queue depth.

Also review your expected email volume. Booking notifications are normally low and spiky, but an account with many Booking Calendars, routing flows, or team members can produce more event traffic than a single scheduling page suggests. Check transactional email pricing against the number of bookings, recipients per booking, and any internal notifications you plan to send.

Conclusion

To send email from OnceHub with Volanea, use OnceHub’s Booking Scheduled webhook as the trigger and a secure server-side endpoint as the integration layer. The endpoint validates OnceHub’s HMAC signature, maps booking.scheduled data into a purposeful email, and calls Volanea’s POST /v1/send endpoint with a protected API key.

The two reliability choices that matter most are verifying the raw webhook body and using OnceHub’s event ID as Volanea’s Idempotency-Key. Together, they help ensure that only authentic booking events trigger messages and that webhook retries do not result in duplicate sends.

FAQ

Does Volanea have a native OnceHub integration?

No. Volanea does not provide a native OnceHub marketplace app or plug-in. Connect OnceHub to a server-side webhook endpoint, then call Volanea’s REST API from that endpoint.

What OnceHub event should trigger a booking confirmation email?

Use the Booking Scheduled webhook trigger. The delivered event type is booking.scheduled, and its data object contains the booking details and form submission fields used for the message.

Where should the Volanea API key be stored?

Store it only in server-side environment secrets or a secret manager used by your serverless function, worker, or backend. It does not belong in OnceHub’s webhook settings, browser code, a public configuration file, or a client-side integration.

How do I stop duplicate emails when OnceHub retries a webhook?

Send the OnceHub event id as Volanea’s Idempotency-Key header and, for stronger protection, store processed event IDs in a database with a unique constraint. Reuse the same key for every retry of the same event.

Why is my OnceHub webhook returning an invalid signature error?

Most often, the handler has parsed or reformatted the JSON before validation. Verify the HMAC using the original raw request body and the Webhook Secret assigned to that specific OnceHub endpoint.