How to Send Email from Monday.com with Volanea

Sending email from Monday.com is useful when a board event should immediately become a customer or teammate notification: a request arrives, a deal reaches a stage, a form creates an item, or a support task is assigned. This guide shows how to send email from Monday.com with Volanea without pretending there is a native marketplace app: Monday.com triggers a webhook, your middleware maps the board data, and Volanea sends the message.

Monday.com does not need to expose your email provider credentials to make this work. In fact, it should not. The durable pattern is:

1. A Monday.com board event triggers a Send webhook automation.
2. Monday.com posts an event payload to an HTTPS endpoint you control.
3. That endpoint fetches any additional item fields it needs from Monday.com.
4. The endpoint calls Volanea's REST API with a server-side API key.
5. Your service records the event ID or item/action combination to prevent duplicate sends.

This is slightly more work than connecting two tools through a native app, but it gives you precise control over recipients, templates, deduplication, deliverability, audit logs, and failure handling.

What the Monday.com integration actually looks like

Monday.com organizes work in boards. A row on a board is called an item, and the cells on that item are column values. For this integration, the most practical concrete trigger is:

When an item is created, send a webhook.

That trigger also covers a common form workflow: when someone submits a Monday.com WorkForm tied to a board, Monday.com creates an item on the connected board. Your item-created webhook can then send the acknowledgement email.

For other workflows, use a more selective event such as a status-column change. For example, a board can send only when an item moves to a status such as Ready to send, Approved, or Won. The important design choice is to use a state that represents a deliberate send decision, not merely an incidental edit.

The integration is not a Volanea app installed from the Monday.com marketplace. Instead, create a webhook automation on the relevant board and point it at a secure endpoint owned by your application, serverless function, or integration service.

Why a middleware endpoint is required

A Monday.com webhook is an event notification. It is not a general-purpose email composer and should not be treated as a place to store an email API secret. The event tells your endpoint that something happened; your endpoint decides whether to send, resolves the item fields, renders content, and uses Volanea credentials securely.

The middleware is also where you solve problems that otherwise become hard to diagnose:

• Look up column values that are not present in the webhook event.
• Enforce recipient rules and consent checks.
• Convert a status label into an approved transactional template.
• Prevent retries from creating duplicate messages.
• Return a fast response to Monday.com even if email delivery takes longer.
• Record the Volanea message ID alongside the Monday.com item ID.

For teams that do not want to host code, Make or Zapier can fill the middleware role. The same security and idempotency principles still apply: receive the Monday event, fetch the item data if needed, map approved fields, then call Volanea from a private connection or server-side secret store.

Choose the right board trigger before writing code

An item-created trigger is simple, but it is not always the correct trigger. A new item might be incomplete, created by an import, or missing the recipient email address. A status change is usually safer when email is an intentional outcome.

Good triggers for outbound email

Use an item-created event when the item itself is the submission or request, such as:

• A WorkForm submission creates a new lead item.
• A customer request board receives a new item.
• An internal onboarding board receives a new employee record.

Use a column-change event when the team needs to approve or control the send, such as:

• Status changes from Draft to Send confirmation.
• Status changes from Pending review to Approved.
• A checkbox or button-like workflow field changes to Send email.
• An owner is assigned and the recipient should receive an assignment notice.

Avoid tying an email to a broad event such as every item update. Item names, dates, owners, and columns can change several times during normal work. If each update sends an email, people receive noisy duplicates and your team ends up treating transactional email as unreliable.

A recommended board design

Create or reuse columns with stable purposes. Do not rely on a human-readable item name to carry multiple values.

Use column IDs in code, not column titles. A board owner can rename Contact name to Primary contact without warning; a stable column ID protects your integration from that presentation-layer change.

The webhook payload Monday.com sends

For an item-created board webhook, Monday.com's event body is an envelope with an event object. The event includes board and item identifiers, but it is intentionally not a full copy of every board column.

A representative item-created payload has this shape:

{
  "event": {
    "app": "monday",
    "type": "create_pulse",
    "triggerTime": "2026-09-22T15:41:18.417Z",
    "subscriptionId": 987654321,
    "userId": 12345678,
    "originalTriggerUuid": "8c3d5664-5b3a-4ca9-8d4e-70c6926c6f59",
    "boardId": 1234567890,
    "groupId": "new_requests",
    "pulseId": 2345678901,
    "pulseName": "Website enquiry",
    "groupName": "New requests"
  }
}

pulseId is Monday.com's legacy event-field name for the item ID. Treat it as the item identifier and use it to fetch the current item data through the Monday.com API. Do not assume that pulseName contains the recipient email, subject, or message body.

For a status update, the event type is commonly update_column_value, and the payload adds the changed column context. Its value describes the changed column value, but it still may not include every other field your email needs. That is why the handler below fetches the item before composing an email.

Map fields deliberately

Suppose a lead board uses these IDs:

• email for the recipient address
• contact_name for the recipient name
• email_subject for a subject line
• email_html for an approved HTML message body
• status for the workflow gate

The mapping should be explicit:

Do not pass arbitrary board content straight into HTML without deciding who may edit it. If multiple collaborators can edit the board, prefer a fixed application template and use the board only for plain-text merge variables.

Set up the Monday.com webhook automation

On the board that owns the workflow, open its automation or integration builder and add the webhook recipe appropriate to your trigger. For the example in this guide, select the recipe equivalent to When an item is created, send a webhook, then paste your HTTPS endpoint, such as:

https://automation.example.com/monday/volanea

For approval-driven messages, configure the status-change webhook instead and limit it to the intended status. For example, configure the automation so it sends the webhook only when the Status column changes to Ready to send.

Your endpoint must handle Monday.com's initial verification request. Monday.com sends a JSON object containing a challenge; the endpoint must respond with that same challenge value. This verifies that the webhook URL belongs to a service able to receive the events.

Keep the endpoint HTTPS-only. Use a long, unguessable route segment or an additional server-side verification approach appropriate for your infrastructure. A webhook endpoint that anyone can invoke is otherwise an email-sending surface.

Keep the Volanea key out of Monday.com

The Volanea API key belongs in your middleware's secret manager, not in any client-visible browser configuration, public board field, webhook URL query string, or item update.

For a Cloudflare Worker, store it as an encrypted Worker secret. For AWS Lambda, use Secrets Manager or an encrypted environment variable. For Vercel, use project environment variables scoped to server functions. For Make or Zapier, use their private connection or secure credential store rather than placing the token in mapped data.

The reason is straightforward: an email API key can authorize sends. If it appears in a browser bundle, a front-end environment variable, an exported board, an automation URL, logs, or screenshots, it can be copied and abused. Rotate a compromised key immediately, then review Volanea activity for unexpected sends.

Working middleware: fetch Monday.com data and send with Volanea

The following Cloudflare Worker example receives a Monday.com webhook, returns the verification challenge when required, queries the item data from Monday.com GraphQL, maps the relevant columns, and makes the Volanea REST request.

Store MONDAY_API_TOKEN, VOLANEA_API_KEY, and VOLANEA_FROM as server-side secrets. Bind a KV namespace called SENT_EVENTS to retain idempotency keys. The example uses the Volanea email endpoint and bearer authentication described in the Volanea API reference.

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

    const payload = await request.json();

    // Monday.com webhook URL verification.
    if (payload.challenge) {
      return Response.json({ challenge: payload.challenge });
    }

    const event = payload.event;
    if (!event?.boardId || !event?.pulseId) {
      return new Response("Ignored: no board item event", { status: 202 });
    }

    // For a status-based automation, only send when the changed value is approved.
    if (event.type === "update_column_value" && event.columnId === "status") {
      const newStatus = event.value?.label?.text;
      if (newStatus !== "Ready to send") {
        return new Response("Ignored: status is not sendable", { status: 202 });
      }
    }

    const idempotencyKey = event.originalTriggerUuid ||
      `${event.subscriptionId}:${event.pulseId}:${event.triggerTime}`;

    if (await env.SENT_EVENTS.get(idempotencyKey)) {
      return new Response("Already processed", { status: 200 });
    }

    const mondayQuery = `
      query GetItem($itemIds: [ID!]) {
        items(ids: $itemIds) {
          id
          name
          column_values(ids: ["email", "contact_name", "email_subject", "email_html"]) {
            id
            text
          }
        }
      }
    `;

    const mondayResponse = await fetch("https://api.monday.com/v2", {
      method: "POST",
      headers: {
        "Authorization": env.MONDAY_API_TOKEN,
        "Content-Type": "application/json"
      },
      body: JSON.stringify({
        query: mondayQuery,
        variables: { itemIds: [String(event.pulseId)] }
      })
    });

    if (!mondayResponse.ok) {
      return new Response("Monday.com lookup failed", { status: 502 });
    }

    const mondayData = await mondayResponse.json();
    const item = mondayData.data?.items?.[0];
    if (!item) return new Response("Item not found", { status: 404 });

    const columns = Object.fromEntries(
      item.column_values.map((column) => [column.id, column.text?.trim() || ""])
    );

    const recipient = columns.email;
    if (!recipient || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(recipient)) {
      return new Response("Ignored: missing or invalid recipient", { status: 202 });
    }

    const name = columns.contact_name || "there";
    const subject = columns.email_subject || `Update for ${item.name}`;
    const html = columns.email_html ||
      `<p>Hello ${escapeHtml(name)},</p><p>We received your request: ${escapeHtml(item.name)}.</p>`;

    const volaneaResponse = await fetch("https://api.volanea.com/v1/emails", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey
      },
      body: JSON.stringify({
        from: env.VOLANEA_FROM,
        to: [recipient],
        subject,
        html,
        metadata: {
          monday_board_id: String(event.boardId),
          monday_item_id: String(item.id),
          monday_event_id: idempotencyKey
        }
      })
    });

    const volaneaBody = await volaneaResponse.text();
    if (!volaneaResponse.ok) {
      console.error("Volanea send failed", volaneaResponse.status, volaneaBody);
      return new Response("Email provider failed", { status: 502 });
    }

    // Mark only after Volanea accepted the request.
    await env.SENT_EVENTS.put(idempotencyKey, volaneaBody, {
      expirationTtl: 60 * 60 * 24 * 30
    });

    return new Response("Email accepted", { status: 200 });
  }
};

function escapeHtml(value) {
  return String(value)
    .replaceAll("&", "&amp;")
    .replaceAll("<", "&lt;")
    .replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;")
    .replaceAll("'", "&#039;");
}

The payload that reaches Volanea is explicit rather than inferred:

{
  "from": "Support <support@yourdomain.com>",
  "to": ["person@example.com"],
  "subject": "We received your request",
  "html": "<p>Hello Jamie,</p><p>We received your request.</p>",
  "metadata": {
    "monday_board_id": "1234567890",
    "monday_item_id": "2345678901",
    "monday_event_id": "8c3d5664-5b3a-4ca9-8d4e-70c6926c6f59"
  }
}

Use a verified sending identity for VOLANEA_FROM, and make the from-domain match the type of message you are sending. A support acknowledgement should normally come from a support or notifications address on your domain, not from a personal employee inbox.

Add a send gate and idempotency before going live

The biggest operational mistake in a board-to-email workflow is treating a webhook as exactly-once delivery. Webhooks are not a guarantee that an event will arrive only once. Network failures, timeouts, retries, manual replays, and changes to automation configuration can all lead to more than one invocation.

Your integration needs two independent protections.

First, gate the event

Only send when the board state clearly authorizes it. A good status flow might be:

New → In review → Ready to send → Sent

The handler should reject messages unless the event is for Ready to send, or unless the item-created workflow meets all eligibility criteria. Once Volanea accepts the email, update the item to Sent or write a send timestamp and message ID through the Monday.com API. That creates a visible operational record for the team.

Second, make sends idempotent

Use originalTriggerUuid when Monday.com supplies it. Store it in a database, KV store, Redis, or queue-backed idempotency table before treating another request as new. Also send it as Volanea's idempotency key where supported.

A robust uniqueness record can include:

• The webhook event UUID.
• The board ID and item ID.
• The email purpose, such as lead-receipt or approval-notification.
• The Volanea response or message ID.
• The accepted timestamp.

Do not mark an event as permanently sent before Volanea accepts the request. If you store it first and the provider call fails, you may accidentally suppress a legitimate retry. A safer implementation uses a short-lived processing lock, then changes it to sent only after acceptance.

When this breaks: Monday.com webhook failure modes

A reliable integration plans for the failure modes at the Monday.com-to-middleware hop, not only the email API call.

Monday.com retries and duplicate emails

If your endpoint times out, responds with a non-success status, or loses the response after sending to Volanea, Monday.com may retry the webhook. Without idempotency, a single form submission can produce two confirmation emails.

Return quickly. Fetch the item, validate it, and call Volanea within your platform's request limit, or place a job on a queue and acknowledge the webhook after durable enqueueing. The queue worker should use the same idempotency key.

Verification challenges fail

A common setup problem is treating every request as an event. During URL verification, Monday.com sends a challenge payload. Return the challenge as JSON exactly as shown in the code. Do not require the handler to fetch an item, authenticate to Volanea, or perform template rendering before returning it.

The payload is missing a field you expected

Webhook events identify what happened; they are not guaranteed to include every custom board field. Also, an item can be created before all automation-populated values, integrations, or human edits have completed.

The solution is not to guess from the item name. Fetch the current item through the Monday.com API and validate each required column. If the email address, consent flag, or subject is blank, return a controlled 202 response, log the reason, and leave the item in a reviewable board state.

Column names change or a board is copied

A copied board may have different column IDs, even if its visible titles look identical. A renamed title can also mislead a future maintainer. Put board IDs, allowed status labels, and column IDs in server-side configuration, then test them after cloning a board or changing the workflow.

Monday.com API permissions or limits block lookups

The Monday.com API token used by middleware must have access to the relevant workspace and board. If it does not, the webhook can arrive successfully while the item lookup fails. Treat that as a separate alert category from a Volanea delivery failure.

Use a least-privilege service identity where your Monday.com setup supports it, document the board permissions it needs, and monitor non-200 API responses. An integration that silently skips requests because of a permissions change is worse than one that fails visibly.

Deliverability rules for board-triggered messages

Automation does not remove email compliance or deliverability responsibilities. A Monday.com item is a workflow record, not automatically proof that an email may be sent.

For transactional messages, send content that directly relates to the user's request or account action: receipt confirmations, appointment updates, access notices, support acknowledgements, and approved service notifications. For promotional content, use explicit subscription and preference management rather than adding every board contact to a campaign.

Before production sending, make sure that:

• Your Volanea sending domain is authenticated with the DNS records shown in its setup flow.
• Your from address belongs to that authenticated domain.
• The recipient field is validated before a send attempt.
• Hard bounces and complaints are not repeatedly retried from board edits.
• Email content contains no unreviewed user-provided HTML.
• You can trace an email back to its Monday.com item and workflow event.

Address validation is particularly useful for form-created items, where typing mistakes are common. You can validate the email field before a full send workflow with the email address verification tool, then route invalid entries to a review status instead of attempting delivery.

Testing the integration safely

Create a dedicated test board first. Use a sender domain that is already authenticated, a mailbox you control, and a test status label such as Ready to send — test.

Run these tests in order:

1. Create an item with every required field and confirm one email reaches the test inbox.
2. Create an item with a blank recipient address and confirm no provider request is made.
3. Use an invalid address and confirm the handler records a controlled failure.
4. Change an unrelated column and confirm no new email is sent.
5. Trigger the approved status twice and confirm idempotency prevents the second send.
6. Temporarily force the Volanea request to fail and confirm the item is not falsely marked as sent.
7. Re-send the same webhook payload to the endpoint and confirm it is recognized as already processed.

Log enough context to investigate incidents without logging unnecessary personal data. Board ID, item ID, event UUID, message purpose, provider status, and provider message ID are usually sufficient. Avoid writing complete message bodies or API tokens to application logs.

Alternatives to a custom webhook handler

A custom serverless handler is the best option when you need predictable retries, data enrichment, custom templates, private secrets, or substantial sending volume. But it is not the only route.

Make or Zapier as middleware

A no-code scenario can start from a Monday.com trigger, fetch the board item, filter by status, and use an HTTP request step to call Volanea. Store the Volanea credential in the platform's connection or secret mechanism, not in a visible mapped field.

This can be appropriate for a small internal workflow. Still design for duplicates: use a persistent data store or an Email sent column check before each send. Also verify how the automation platform behaves when an HTTP step times out or is replayed.

A queue-backed integration service

For high-value customer messages, receive the webhook, validate it, and publish a job to a durable queue. A separate worker fetches data, renders the message, sends via Volanea, and writes the result back to Monday.com. This takes more infrastructure but makes outages, retries, rate limits, and audit trails easier to manage.

The right choice depends on the cost of a missed email versus the cost of a duplicate. Payment, access, and compliance notifications deserve queueing and detailed state tracking. Low-risk internal notifications may be well served by a simpler handler.

Conclusion

To send email from Monday.com with Volanea, use Monday.com's board webhook capability as the trigger and a secure middleware endpoint as the decision and delivery layer. An item-created event is ideal for form and request confirmations; a status-change event is better when a teammate must approve the send.

The key implementation details are straightforward but important: use Monday.com's item ID to retrieve current column values, map stable column IDs to Volanea fields, store the Volanea API key only on the server, return webhook verification challenges correctly, and make every send idempotent. With those safeguards in place, a Monday.com board becomes a dependable source of transactional email events rather than a source of accidental duplicate sends.

FAQ

Can Monday.com send directly to Volanea without middleware?

Not safely for a production workflow. A Monday.com webhook can notify an HTTPS endpoint, but middleware is where you securely keep the Volanea API key, fetch complete item data, validate recipients, render content, and prevent duplicate sends.

What Monday.com event should trigger the email?

Use When an item is created, send a webhook for request or form acknowledgement flows. Use a status-column change, such as moving an item to Ready to send, when a person should approve the message before it goes out.

Why does the webhook use pulseId instead of itemId?

pulseId is a legacy Monday.com event name for the board item identifier. Use it as the item ID when querying Monday.com's API for the item's current column values.

How do I stop duplicate emails after a webhook retry?

Store Monday.com's originalTriggerUuid as an idempotency record and pass the same value as the provider idempotency key. Only mark it as sent after Volanea accepts the email request.

Where should the Volanea API key be stored?

Store it as a server-side secret in your middleware platform, such as a Worker secret, encrypted environment variable, or secret manager. Never put it in a board field, webhook URL, browser code, or a client-visible environment variable.