Send transactional email from Pipedrive without treating your CRM as an email delivery API. The dependable pattern is to let Pipedrive Automation send a webhook to your serverless endpoint, then have that endpoint authenticate to Volanea and send the email.

There is an important boundary to understand before building this: Volanea does not currently have a native Pipedrive app or one-click marketplace integration. You will not install a Volanea app inside Pipedrive. Instead, you connect the two systems using Pipedrive’s Automation webhook action and an HTTP relay you control.

That extra relay is not unnecessary complexity. It keeps your Volanea secret key out of Pipedrive, gives you a place to validate data, turns retries into safe sends with idempotency, and lets you choose exactly which CRM events deserve an email. This guide walks through the full implementation with a practical example: when a deal reaches a particular stage, send the linked person a next-steps email.

What this Pipedrive-to-Volanea workflow does

The workflow has four moving parts:

A Pipedrive deal, person, lead, or activity changes.
A Pipedrive Automation rule evaluates its trigger and conditions.
The automation sends an HTTP webhook request containing the fields you chose in its body builder.
Your endpoint validates that request and calls Volanea’s POST /v1/send endpoint with a secret key kept in environment variables.

This is a transactional-email architecture, not a bulk campaign workflow. Use it for messages that are directly connected to a customer action or sales-process event, such as:

A meeting confirmation after an activity is created.
A proposal follow-up when a deal enters a proposal stage.
A document or onboarding link after a deal is marked won.
A notification that a requested resource is ready.
A time-sensitive reminder when an activity becomes due.

The distinction matters. A stage-based message can be transactional when it provides an expected operational update, but a broad promotional sequence is marketing mail. Do not use a CRM stage change as a shortcut around consent, unsubscribe, or suppression requirements for marketing communication.

Why you need a webhook relay instead of calling Volanea directly

It may be tempting to point Pipedrive’s webhook directly at https://api.volanea.com/v1/send. Do not do that.

Volanea’s send endpoint requires secret-key authentication. Pipedrive Automation webhooks let you configure an endpoint, HTTP method, request body, and optional HTTP authentication credentials, but they are not a safe place to place a reusable Volanea bearer token in a custom authorization header. A direct call would either fail authentication or require exposing a high-value credential in a system that should not hold it.

A small relay solves this cleanly:

Pipedrive Automation
       |
       | POST JSON + optional HTTP Basic Auth
       v
Your webhook endpoint
       |
       | validates, normalizes, deduplicates
       | Authorization: Bearer sk_...
       v
Volanea POST /v1/send
       |
       v
Recipient inbox

The relay can run as an Express service, Cloudflare Worker, Vercel Function, AWS Lambda, or any application endpoint that can accept HTTPS requests. The example below uses Node.js with Express because the request flow is easy to inspect, but the design is portable.

The relay should own four responsibilities:

Authentication: reject requests that do not come with the credentials you configured in Pipedrive.
Validation: reject malformed email addresses and incomplete message inputs before they become sends.
Message construction: create subject, text, and HTML from trusted server-side templates.
Idempotency: create a stable key so a retry does not generate a second customer email.

For the underlying endpoint, authentication, and send fields, keep the email API reference and setup guides close while you build. It is better to verify the current request contract than to copy an old payload from a blog post.

How Pipedrive Automation webhooks actually send data

Pipedrive has two related webhook concepts that are easy to confuse:

Regular webhooks subscribe to broad Pipedrive object events and deliver Pipedrive’s webhook event envelope to your endpoint.
Automation webhooks are actions inside an Automation rule. They are the right fit here because you can apply workflow conditions and construct a custom request body from Pipedrive fields.

For this guide, use an Automation webhook, not a regular general webhook. In Pipedrive, Automation webhooks are configured before they can be selected inside an automation. The webhook configuration includes a name, endpoint URL, and optional authentication credentials. The later Automation action requires a webhook, method, and body; Pipedrive supports POST, PUT, and DELETE, plus key-value and raw JSON body builders.

There is no single fixed Automation webhook payload

This is crucial: Pipedrive Automation does not send one universal, provider-defined JSON payload. The payload shape is the body you build in the automation. That is why two Pipedrive Automation webhook examples can look completely different while both are correct.

For a direct integration, the best approach is to define a deliberately small contract. Do not forward every possible deal field. Send only what the relay needs to identify the trigger, recipient, and business context.

Configure the Pipedrive Automation action with a Raw JSON body that resolves to this shape at runtime:

{
  "eventId": "pipedrive-deal-4821-proposal-follow-up",
  "eventType": "deal.stage_changed",
  "deal": {
    "id": 4821,
    "title": "Website redesign — Acme Inc."
  },
  "person": {
    "id": 911,
    "name": "Avery Morgan",
    "email": "avery@example.com"
  },
  "owner": {
    "name": "Jordan Lee"
  },
  "message": {
    "kind": "proposal_follow_up"
  }
}

In the raw body editor, use Pipedrive’s field picker to insert the current deal ID, deal title, linked person name, linked person email, owner name, and any custom field you need. The values shown above are an example of the resolved HTTP body your endpoint receives, not placeholder syntax to paste into Pipedrive.

That distinction protects you from a common setup error: manually typing made-up merge tags that Pipedrive will send literally. Build the JSON structure yourself, but insert dynamic CRM values through the Pipedrive field selector.

Create a useful event ID

An event ID is not just an implementation detail. It is what lets the same workflow execution be safely retried.

For a stage-triggered email, build an identifier from values that represent one intended email, such as:

pipedrive-deal-{deal-id}-proposal-follow-up

If the same deal may legitimately receive the same type of email again later, include an additional stable business value, such as a proposal version, an activity ID, or a date-specific workflow key. Do not use the current timestamp by itself: retries would generate a new key and could send duplicates.

Set up the Pipedrive automation

Start by deciding the event that should cause an email. A useful first workflow is: when a deal changes to the Proposal Sent stage, email the linked person with next steps.

Before creating it, make sure each eligible deal has a linked person with a real email address. It is much easier to prevent incomplete records in the workflow conditions than to handle them as delivery failures later.

Create the Automation webhook connection

In Pipedrive, open the webhook area under Settings, then create an Automation webhook. Pipedrive’s current documentation indicates that Automation webhooks and Automations are available on Advanced and higher plans, and only global admins can create the Automation webhook connection.

Use these values conceptually:

Setting	Example
Webhook name	`Volanea transactional relay`
Endpoint URL	`https://hooks.example.com/`
HTTP authentication username	a long random identifier
HTTP authentication password	a separate long random secret

Pipedrive requires the base endpoint URL to end in /, &, ?, or =. If you need a more specific path, use Pipedrive’s path option in the automation action to append it. For example, your base URL can be https://hooks.example.com/ and the automation path can route to a Pipedrive-specific endpoint in your deployment.

Use HTTPS. Do not expose a development endpoint to production CRM traffic, and do not rely on an obscure URL as the only access control.

Build the rule and conditions

Create a new automation under Tools and apps > Automations. Pick a deal update trigger, then add conditions that narrow it to one intentional event.

For the proposal example, the conditions should answer questions like:

Did the deal enter the intended stage rather than merely get edited?
Does the deal have a linked person?
Is that person’s primary email present?
Is the deal not marked lost, archived, or otherwise ineligible?
Has this message type already been sent if your CRM data model tracks it?

Then choose the webhook action, select the Automation webhook you created, choose POST, and use the Raw body builder to define the message contract.

Avoid workflows triggered by every deal update unless the conditions are extremely precise. A routine edit to a deal title, value, owner, or custom field can otherwise become an unexpected customer email.

Test from Pipedrive before enabling the workflow

Pipedrive’s Automation execution history shows whether the action ran and includes the final request body and path produced by the automation. Use it to confirm that:

The linked person email resolved to an actual address.
The event ID is stable and not empty.
JSON remains valid after field insertion.
Names, deal titles, and custom fields do not contain unexpected data.
The endpoint returns a successful response.

Run the first live test against an internal address, not a customer. A successful automation execution only proves that Pipedrive reached your relay. You still need the relay logs and Volanea response to confirm that the message was accepted for sending.

Build the secure Node.js webhook relay

The following Express endpoint accepts the custom Automation webhook body described above, verifies HTTP Basic Auth, validates the core fields, and sends the email through Volanea.

Install Express:

npm install express

Set environment variables in your hosting provider rather than committing them to source control:

VOLANEA_API_KEY=sk_...
PIPEDRIVE_WEBHOOK_USER=replace-with-random-user
PIPEDRIVE_WEBHOOK_PASSWORD=replace-with-random-password
EMAIL_FROM="Acme Team <updates@your-verified-domain.com>"
PORT=3000

Use a sending address on a domain you have authenticated in Volanea. The sender domain is part of deliverability, not just branding. SPF, DKIM, and DMARC alignment should be handled before you begin sending customer-facing production traffic.

Here is the complete relay:

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

const app = express();

// Parse the body regardless of whether the caller sets an ideal JSON content type.
app.use(express.text({ type: "*/*", limit: "100kb" }));

function unauthorized(res) {
  res.set("WWW-Authenticate", 'Basic realm="pipedrive-relay"');
  return res.status(401).json({ error: "Unauthorized" });
}

function validEmail(value) {
  return typeof value === "string" &&
    /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value.trim());
}

app.post("/", async (req, res) => {
  const authorization = req.get("authorization") || "";
  const expected = Buffer.from(
    `${process.env.PIPEDRIVE_WEBHOOK_USER}:${process.env.PIPEDRIVE_WEBHOOK_PASSWORD}`
  ).toString("base64");

  if (authorization !== `Basic ${expected}`) {
    return unauthorized(res);
  }

  let payload;
  try {
    payload = JSON.parse(req.body);
  } catch {
    return res.status(400).json({ error: "Request body must be valid JSON" });
  }

  const recipientEmail = payload?.person?.email?.trim().toLowerCase();
  const recipientName = payload?.person?.name?.trim() || "there";
  const dealTitle = payload?.deal?.title?.trim() || "your proposal";
  const ownerName = payload?.owner?.name?.trim() || "our team";
  const eventId = payload?.eventId;

  if (!eventId || typeof eventId !== "string") {
    return res.status(422).json({ error: "eventId is required" });
  }

  if (!validEmail(recipientEmail)) {
    return res.status(422).json({ error: "A valid person.email is required" });
  }

  if (payload?.message?.kind !== "proposal_follow_up") {
    return res.status(422).json({ error: "Unsupported message kind" });
  }

  const subject = `Next steps for ${dealTitle}`;
  const text = [
    `Hi ${recipientName},`,
    "",
    `Thanks for your time. We have prepared the next steps for ${dealTitle}.`,
    "",
    `Reply to this email if you have questions.`,
    "",
    `${ownerName}`
  ].join("\n");

  // Escape untrusted CRM values before placing them into HTML.
  const escapeHtml = (value) => String(value)
    .replaceAll("&", "&amp;")
    .replaceAll("<", "&lt;")
    .replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;")
    .replaceAll("'", "&#039;");

  const html = `
    <p>Hi ${escapeHtml(recipientName)},</p>
    <p>Thanks for your time. We have prepared the next steps for <strong>${escapeHtml(dealTitle)}</strong>.</p>
    <p>Reply to this email if you have questions.</p>
    <p>${escapeHtml(ownerName)}</p>
  `;

  const idempotencyKey = crypto
    .createHash("sha256")
    .update(`pipedrive:${eventId}`)
    .digest("hex");

  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": idempotencyKey
    },
    body: JSON.stringify({
      from: process.env.EMAIL_FROM,
      to: [recipientEmail],
      subject,
      text,
      html
    })
  });

  const result = await volaneaResponse.json().catch(() => ({}));

  if (!volaneaResponse.ok) {
    console.error("Volanea send failed", {
      status: volaneaResponse.status,
      eventId,
      result
    });

    return res.status(502).json({
      error: "Email provider rejected the send",
      eventId
    });
  }

  console.info("Transactional email accepted", {
    eventId,
    recipientEmail,
    status: volaneaResponse.status
  });

  return res.status(202).json({ ok: true, eventId });
});

app.listen(process.env.PORT || 3000, () => {
  console.log("Pipedrive relay is listening");
});

What makes this code safe to use as a starting point

The code intentionally does not accept a subject line, HTML body, sender address, or Volanea key from Pipedrive. Those values should stay under application control.

That prevents a CRM field from becoming an arbitrary-email interface. A user who can edit a deal should not automatically gain the ability to send any HTML they choose, impersonate another sender, or choose an unrestricted recipient list.

The relay only accepts one known message.kind, maps that kind to a server-side message, and allows the Pipedrive payload to provide business context. As your workflow grows, use a server-side allowlist such as proposal_follow_up, meeting_confirmation, and onboarding_ready, each with its own template and required fields.

Understand the Volanea send request

The relay sends this request to Volanea:

POST https://api.volanea.com/v1/send
Authorization: Bearer sk_...
Content-Type: application/json
Idempotency-Key: 2f7c...

{
  "from": "Acme Team <updates@your-verified-domain.com>",
  "to": ["avery@example.com"],
  "subject": "Next steps for Website redesign — Acme Inc.",
  "text": "Hi Avery Morgan,\n\nThanks for your time...",
  "html": "<p>Hi Avery Morgan,</p><p>Thanks for your time...</p>"
}

Volanea’s single-message send endpoint is POST /v1/send; it accepts one recipient or up to 50 recipients in a send request. For an event from a single Pipedrive person, send one recipient at a time. That keeps activity, consent logic, personalization, and support investigations much clearer.

The Idempotency-Key header is especially important in a webhook workflow. Network timeouts create ambiguity: Pipedrive may retry because it did not receive your response even if your relay already reached Volanea. Reusing the same key for the same business event lets Volanea handle a repeat submission safely instead of creating another message.

Do not confuse an accepted API request with an inbox placement guarantee. Acceptance means the provider received and processed the request. Delivery, bounce handling, complaints, and engagement are later stages that should be monitored through your email infrastructure.

Improve the design before adding more automations

A working proof of concept should become a production workflow before it starts sending important customer communications. The following improvements have an outsized payoff.

Use templates for stable layouts

Inline HTML is fine for a first relay, but it becomes difficult to maintain once you have multiple message types, branding changes, localization, or legal footer requirements. Move stable content into Volanea templates when the template model fits the message.

Keep the rule that the Pipedrive webhook supplies data, not arbitrary markup. Your service should decide which template corresponds to each allowed message kind and provide only the expected personalization fields.

Add application-level duplicate protection

Volanea idempotency protects repeated send calls that use the same key. You should still record the business event in your own database or durable key-value store when the consequences of duplicates are high.

For example, store:

pipedrive_event_id | message_kind | deal_id | recipient | volanea_message_id | sent_at

That record helps you answer operational questions later: Was the email already requested? Which deal event caused it? Which recipient received it? Did the workflow run twice because someone moved a deal back and forth between stages?

Validate addresses before valuable workflows

A CRM contact may have an empty email, a typo, an old address, or a role address that is not appropriate for the message. Basic syntax validation in code prevents obvious bad input, but it does not establish whether a mailbox is deliverable.

For high-value messages or imported lists, use an email address verification tool before the send becomes part of a repeatable workflow. Verification should complement, not replace, bounce processing and suppression handling.

Separate test and production paths

Use Volanea test credentials for relay development and internal validation. Keep a separate production endpoint or environment for live Pipedrive workflows. Never point an untested automation at live customer data simply because the endpoint responds with HTTP 200.

A simple rollout sequence is:

Send to one internal test contact from a test deal.
Confirm payload values in Pipedrive execution history.
Confirm your relay logs the event ID without logging secrets.
Confirm Volanea accepts the message and the received email has correct rendering.
Test a deliberate retry with the same event ID.
Enable the workflow for a small, monitored production segment.

Security, privacy, and deliverability considerations

Pipedrive data is customer data. Treat the webhook body as sensitive even if it contains only a name, email address, and deal title.

Do not log the raw body indefinitely. Log a minimum useful audit record, redact credentials, restrict log access, and set a retention period. If a deal title can contain confidential project information, consider logging the deal ID and message kind rather than the full title.

Use the HTTP Basic Auth credentials configured on the Pipedrive Automation webhook as a first layer of request authentication. Make both values long and random, store them as secrets, and rotate them if they are exposed. If your deployment platform provides additional controls, consider an IP allowlist only when Pipedrive publishes and supports stable delivery ranges for your use case; do not assume an unofficial IP list is permanent.

For email delivery, authenticate your sender domain before production. A recognizable From address on a properly authenticated domain supports recipient trust and gives mailbox providers the technical signals they expect. Use a real reply path, and make sure replies reach a team that can respond.

Finally, honor suppression and unsubscribe requirements appropriate to the message type. Transactional does not mean unrestricted. A recipient who has complained, hard-bounced, or explicitly asked not to receive a class of messages should not continue to receive it because a CRM automation fired.

Common implementation mistakes

Sending directly from Pipedrive to Volanea

This fails the secret-management test. Your Volanea bearer key belongs in a backend secret store, not in a workflow configuration or request body.

Treating the Automation payload as a fixed Pipedrive schema

Automation webhook bodies are configurable. Build and test the exact JSON contract you expect. If you later switch to Pipedrive’s general webhooks, do not reuse this parser without adapting it to Pipedrive’s regular event envelope.

Putting untrusted fields straight into HTML

A contact name or deal title can contain characters that break markup. Escape dynamic values, as the example does, or use a template engine that escapes variables by default.

Returning success before Volanea accepts the send

If your relay returns HTTP 200 before making the Volanea request, Pipedrive sees a successful automation even if the email never reaches your provider. Wait for the provider response and return an error status when the send is rejected.

Using a random idempotency key for every attempt

A new random key makes retries look like new sends. Derive the key from a stable event identifier that represents one intended customer message.

Triggering on any deal change

A broad trigger causes accidental email. Make the triggering transition explicit, and add guard conditions for recipient presence, deal state, message eligibility, and repeat sends.

When to use Pipedrive’s native email automation instead

Pipedrive can send automated emails through connected email accounts. That is a good fit when the message is a straightforward sales follow-up and your team needs the conversation to remain in the normal Pipedrive email workflow.

Use the webhook-plus-Volanea pattern when you need application-controlled sending, a verified sending domain, custom transactional rendering, server-side business logic, independent API observability, or an event that needs to coordinate with systems outside Pipedrive.

The two approaches can coexist. A sales rep’s human follow-up may stay in Pipedrive, while a predictable product, onboarding, billing, or operational notification goes through your relay and transactional email API.

Conclusion

To send transactional email from Pipedrive using Volanea, build a Pipedrive Automation webhook that posts a small, intentional JSON payload to a secure endpoint you control. That endpoint validates the event, maps it to a server-side message, and makes an authenticated POST /v1/send request to Volanea.

This approach is more honest and more robust than claiming a native integration exists. Pipedrive remains the source of the CRM event; your relay owns security and business rules; Volanea handles the transactional send. Once that foundation is in place, you can add message types, templates, event monitoring, and durable audit records without turning CRM fields into an uncontrolled email system.

FAQ

Is there a native Volanea integration for Pipedrive?

No. The implementation described here uses Pipedrive’s Automation webhook capability plus your own HTTP relay, which then calls Volanea’s REST API.

Can Pipedrive call the Volanea API directly?

It should not. Volanea’s REST API uses a secret bearer key, and that key should remain in a server-side secret store. Use a relay to keep it out of Pipedrive and to validate incoming CRM data.

What payload does a Pipedrive Automation webhook send?

There is no one fixed payload. In an Automation webhook action, you construct the request body with Pipedrive’s key-value or Raw JSON builder. The example payload in this guide is a recommended contract to configure and test.

How do I stop duplicate transactional emails?

Create a stable event ID in the Pipedrive payload and derive a stable Idempotency-Key from it in your relay. Also keep an application-level send record for important workflows.

Can I use Zapier or Make instead of writing a relay?

Yes, if the platform can securely store your Volanea key, receive the Pipedrive event, and make the authenticated REST request. A dedicated relay is usually preferable when you need precise validation, HTML templating, audit logging, and dependable duplicate prevention.

How to Send a Transactional Email from Pipedrive Using Volanea