Sending an email from DocuSign can mean more than relying on the signing notifications DocuSign sends automatically. With DocuSign Connect and Volanea, your application can react to an envelope event and send an operational, branded, or internal follow-up email through your own email infrastructure.

DocuSign does not provide a native Volanea application, Marketplace listing, or one-click integration. The reliable approach is a small server-side integration: DocuSign Connect delivers an envelope-event webhook to an HTTPS endpoint you control, the endpoint validates and deduplicates that event, and it calls Volanea’s REST API to send the message.

What this integration does

The trigger in this guide is a DocuSign envelope status change. Specifically, the example responds when an envelope reaches the completed status. In DocuSign terminology, an envelope is the container for the documents, recipients, and routing rules involved in a signature workflow. An envelope becomes completed after its signing process has finished according to its configured routing.

That event is useful because it is an authoritative workflow boundary. A customer-success team may need an internal alert, an account owner may need a next-steps email, or an operations system may need to notify a downstream recipient that a signed agreement is ready for review. These are messages your product owns, rather than the standard recipient notifications DocuSign generates.

The flow is:

  1. A sender creates and sends a DocuSign envelope through the DocuSign application or API.
  2. The envelope reaches completed.
  3. DocuSign Connect POSTs an event notification to your public HTTPS listener.
  4. Your listener checks the request, extracts the envelope and recipient data, and records an idempotency key.
  5. The listener sends an email through Volanea’s REST API.
  6. The listener returns a successful HTTP response to DocuSign only after it has safely accepted the event.

This distinction matters: Connect is a webhook delivery mechanism, not a workflow that can directly reshape an envelope event into an arbitrary email API request. A middleware endpoint is where transformation, authorization, retry handling, audit logging, and business rules belong.

Why use DocuSign Connect rather than a client-side call

DocuSign Connect is DocuSign’s webhook capability. A Connect configuration specifies which envelope events should be reported and the listener URL to which DocuSign delivers them. For an envelope-completed workflow, configure Connect to send notifications for completed envelopes and choose JSON event data where that option is available in your configuration.

A browser-based integration is the wrong architecture for this job. It would expose a Volanea API key to a page visitor, make requests dependent on a user leaving a browser tab open, and give an attacker a straightforward path to reuse your sending credentials. It also would not be the recipient of DocuSign’s server-to-server event delivery.

A serverless function, container service, or ordinary application route is a better listener. It can receive a POST request over HTTPS, verify that it is a Connect delivery, make a decision based on the envelope state, and call Volanea without exposing credentials.

Choose a deliberately narrow event scope

Start with one envelope status: completed. Do not subscribe to every event and then filter casually if the business requirement is only a signed-agreement follow-up. A narrower configuration reduces request volume, makes event history easier to interpret, and lowers the chance that a voided, declined, or delivered event triggers the wrong message.

Later, separate rules can handle other states. For example, declined may notify an account manager, while voided may notify an operations queue. Those messages have different audiences and language, so they should not share a single generic template merely because they originate from the same envelope.

Configure the DocuSign Connect trigger

Set up a Connect configuration at the account level if the workflow should apply broadly, or use an envelope-level event notification when the event subscription belongs to a particular API-created envelope. The exact availability and administration path depend on the DocuSign account, permissions, and product configuration, so confirm the options in the Connect area of the DocuSign Admin experience or through the eSignature API configuration used by your account.

For this use case, the configuration should have these properties:

  • A publicly reachable HTTPS listener URL, such as https://integrations.example.com/webhooks/docusign.
  • An envelope event selection that includes completion.
  • JSON payload delivery, when configuring event data through the API or the relevant Connect settings.
  • HMAC signing enabled, where supported by your Connect configuration, with the secret stored only by your receiving service.
  • No document bytes included unless the receiving service genuinely needs them.

Including documents can make webhook requests much larger and slower. It is usually unnecessary for an email that says an agreement has completed. If a later workflow needs a signed PDF, retrieve it through an authenticated DocuSign API call after processing the event, or use an approved document-storage workflow; do not assume that a generic completion event will always contain a document attachment.

Test the listener before enabling production events

Your listener must be publicly reachable and must present a valid TLS certificate. A private development URL, a localhost address, or a route protected by an interactive login page will not work for a server-to-server webhook.

Use a separate test endpoint and a test mailbox first. Send a test envelope through the intended routing path, complete it, and capture the unmodified request body in secure logs. This establishes what your account’s Connect configuration actually sends. It is especially important if envelope custom fields, tabs, recipient roles, or document-related data are part of your business logic.

Understand the Connect payload before mapping fields

A JSON Connect event is an event wrapper around envelope data. The precise fields delivered depend on the event-data configuration, API version, event type, and fields that exist on the source envelope. The important fact is that data is nested: high-level delivery metadata appears beside a data object that represents the envelope.

A representative completed-envelope event has this shape:

{
  "event": "envelope-completed",
  "apiVersion": "v2.1",
  "uri": "/envelopes/9dbf3f8e-1111-2222-3333-18eb4c4f0e99",
  "retryCount": 0,
  "configurationId": 123456,
  "generatedDateTime": "2026-10-03T15:24:12.000Z",
  "data": {
    "envelopeId": "9dbf3f8e-1111-2222-3333-18eb4c4f0e99",
    "status": "completed",
    "emailSubject": "Acme Services Agreement",
    "recipients": {
      "signers": [
        {
          "recipientId": "1",
          "name": "Avery Chen",
          "email": "avery@example.test",
          "status": "completed"
        }
      ]
    }
  }
}

Treat this as a representative shape, not a contract that every account will emit every time. In particular, recipient groups may contain more than signers; a recipient may not have the same fields as a signer; custom envelope data is not automatically present; and configurations that use XML rather than JSON need a different parser. Your service should reject or safely quarantine unexpected payloads rather than guessing at missing values.

For an internal completion alert, a sensible mapping is data.envelopeId to the email’s audit context, data.emailSubject to a human-readable agreement name, and the first completed signer’s name and address into the message body. The email recipient is an internal, pre-approved address such as contracts@example.com, not blindly a webhook-supplied address.

That last rule prevents an important class of abuse. If a webhook field determines the to address, a user who can influence envelope recipient data may be able to make your system send messages to arbitrary destinations. Only send to a webhook-derived recipient when that is explicitly the product requirement and the address has passed your own authorization and validation rules. For one-off address checks, use the email address verification tool before placing an address into an operational workflow.

Send the Volanea email from secure middleware

The following Node.js example shows the full mapping for an internal completion alert. It assumes your Connect configuration delivers JSON and that an upstream proxy supplies the raw request body to your signature-verification middleware if you enable HMAC verification. The POST /v1/email/send request uses a Volanea API key held in the server environment, never in the DocuSign configuration or browser code.

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

const app = express();
app.use(express.json({ limit: "1mb" }));

const sentEvents = new Set(); // Replace with a database table in production.

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

app.post("/webhooks/docusign", async (req, res) => {
  const event = req.body;
  const envelope = event?.data;

  // Only process the DocuSign envelope-completed event we subscribed to.
  if (event?.event !== "envelope-completed" || envelope?.status !== "completed") {
    return res.sendStatus(204);
  }

  const envelopeId = envelope.envelopeId;
  if (!envelopeId) {
    console.error("Connect event has no data.envelopeId", { event: event?.event });
    return res.sendStatus(400);
  }

  // DocuSign can retry delivery. Make each completion event idempotent.
  const eventKey = `${event.configurationId ?? "unknown"}:${envelopeId}:completed`;
  if (sentEvents.has(eventKey)) return res.sendStatus(200);

  const completedSigner = (envelope.recipients?.signers ?? [])
    .find((signer) => String(signer.status).toLowerCase() === "completed");

  const agreementName = envelope.emailSubject || "Untitled DocuSign envelope";
  const signerName = completedSigner?.name || "A recipient";
  const signerEmail = completedSigner?.email || "an unavailable address";

  const volaneaResponse = await fetch("https://api.volanea.com/v1/email/send", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      from: { email: "notifications@example.com", name: "Example Contracts" },
      to: [{ email: "contracts@example.com", name: "Contracts Team" }],
      subject: `Completed: ${agreementName}`,
      html: `<p><strong>${escapeHtml(signerName)}</strong> completed an envelope.</p>
             <p><strong>Agreement:</strong> ${escapeHtml(agreementName)}<br>
             <strong>Envelope ID:</strong> ${escapeHtml(envelopeId)}<br>
             <strong>Signer:</strong> ${escapeHtml(signerEmail)}</p>`,
      text: `${signerName} completed an envelope. Agreement: ${agreementName}. Envelope ID: ${envelopeId}. Signer: ${signerEmail}.`,
      headers: {
        "X-DocuSign-Envelope-ID": envelopeId
      }
    })
  });

  if (!volaneaResponse.ok) {
    const detail = await volaneaResponse.text();
    console.error("Volanea send failed", { status: volaneaResponse.status, detail, envelopeId });
    return res.sendStatus(500); // Allows DocuSign delivery retry where configured.
  }

  sentEvents.add(eventKey);
  return res.sendStatus(200);
});

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

The mapping is intentionally explicit. data.emailSubject becomes the agreement label, data.envelopeId becomes an auditable identifier, and the signer fields are rendered only after HTML escaping. The Volanea request’s from, to, and API key are owned by your service, not by event data. Before deploying, confirm the endpoint and request fields against the current email API reference and setup guides, especially if your account uses a different API version or sending model.

Do not use an in-memory set in production

The Set in the example explains the idempotency decision, but it disappears when the process restarts and does not coordinate across multiple instances. Use a durable store with a unique constraint on an event key instead. A database table keyed by Connect configuration ID, envelope ID, and final status is usually enough for a completion-only rule.

Record the Volanea message identifier alongside that key after a successful send. This creates a useful audit chain: DocuSign envelope ID, Connect delivery event, your idempotency record, and the email provider’s message ID. It also gives support teams a way to investigate “was the alert sent?” without searching raw webhook payloads.

Keep Volanea authentication on the server

Create a Volanea API key with only the access needed for the integration and store it in a server-side secret manager or encrypted environment variable such as VOLANEA_API_KEY. The runtime that receives the webhook reads it and adds it to the Authorization header when calling Volanea.

Do not put that key in any of these places:

  • DocuSign envelope fields, custom fields, tabs, or recipient data.
  • A Connect listener URL query string.
  • Browser JavaScript, mobile application code, or a public repository.
  • Client-visible automation configuration or front-end environment variables.
  • Application logs, exception messages, or raw request captures.

A sending API key is a credential with real consequences. Anyone who obtains it may be able to send mail as an authorized sender, consume sending capacity, harm domain reputation, or access API functionality allowed by that key. A webhook URL itself is not a safe secret store either; URLs are often copied into logs, monitoring systems, and configuration exports.

Use a separate secret for DocuSign Connect request verification where HMAC signing is enabled. That secret validates the inbound request; it is not the Volanea API key and should not be reused as one. Verify the signature against the raw payload according to DocuSign’s Connect HMAC documentation before parsing or acting on the message.

Design the email around the actual business event

A completed envelope is not always a completed business process. One team might consider the agreement final only after a counter-signature. Another may need to wait for a CRM record update or a payment event. Your middleware is the place to express that distinction.

For example, the first completed signer is not necessarily the signer you care about in a multi-recipient route. A better implementation can select recipients by a known recipient role, use a specific custom field retrieved from the DocuSign API, or require that all relevant recipient statuses meet your rule. Avoid deriving legal, financial, or access-control decisions solely from a convenient display name.

Useful message patterns

The integration commonly supports three patterns:

  • Internal alert: Send a fixed operations, legal, or sales mailbox a concise completion notice with the envelope ID.
  • Customer next step: Send the customer a message from your application after your own system confirms the correct post-signing state.
  • System notification: Notify an account owner or workflow service that it can begin provisioning, archival, or review.

For customer-facing mail, include a clear reason they are receiving it and avoid attaching confidential document contents unless the security model explicitly permits it. If the email links to a document, use an application-authenticated destination with appropriate access checks rather than placing sensitive data in a URL.

When this breaks: retries, timeouts, and incomplete data

Webhook integrations fail at boundaries, so plan for the specific DocuSign-to-middleware-to-Volanea hop rather than treating it as a single request.

First, DocuSign can retry a Connect delivery when it does not receive a successful response. A timeout after Volanea accepted the email is the classic duplicate-send problem: your service may have created the email, but DocuSign may not know that because the 200 response was lost or delayed. Idempotency is therefore not optional. Reserve the event key before sending or use a transactional outbox pattern that records a pending job, sends it once, and marks it complete after the Volanea response.

Second, do not make webhook processing slower than necessary. Fetching large documents, making multiple CRM calls, or rendering complex templates before returning a response increases timeout risk. A robust design stores a validated event and enqueues background work, then responds successfully once the durable handoff is complete. The worker performs the Volanea call with its own retry policy and retains the idempotency key.

Third, payload fields can be absent. Connect event content is shaped by the event-data settings, the envelope’s actual data, and features available to the relevant DocuSign account or plan. Do not assume custom fields, recipient details, document information, or every optional object is present. Validate required paths such as data.envelopeId, use safe fallbacks for optional display fields, and retrieve richer envelope information through the authenticated DocuSign API only when needed.

Fourth, distinguish retryable from non-retryable outcomes. A transient Volanea 5xx response or network failure may merit a controlled retry. A malformed webhook, a missing required envelope ID, or an unauthorized sender configuration should create an alert and stop automatic repetition until corrected. Blind retries can turn one configuration error into a large stream of failed events.

Finally, protect observability. Log the envelope ID, Connect configuration ID, event type, retry count when present, and Volanea response status. Redact recipient addresses and never log authorization headers. Add an alert for repeated failure of the same event key, because that is often a configuration, sender-domain, or payload-assumption problem rather than a temporary outage.

Alternatives when you cannot host middleware

If you cannot operate a public HTTPS endpoint, an automation platform can act as the middle layer only if it supports the required DocuSign event trigger and can securely call Volanea’s HTTP API. Zapier and Make offer DocuSign integrations and HTTP/webhook actions, but their exact trigger availability, task limits, data retention, and authentication controls vary by plan and can change.

The automation route is reasonable for low-volume internal alerts. Configure the automation so the DocuSign envelope-completed event triggers a server-side HTTP request, keep the Volanea API key in the platform’s protected connection or secret facility, and add duplicate protection where the platform permits it. Test retries carefully: an automation rerun plus a DocuSign redelivery can still produce two sends.

For regulated, high-volume, or customer-facing communications, custom middleware is generally the stronger choice. It gives you raw-event verification, durable idempotency, precise logging, queue control, and the ability to replace one downstream service without rebuilding the DocuSign event subscription.

Production checklist

Before turning on the integration for live envelopes, verify each item below:

  1. The Connect configuration listens only for the envelope statuses your workflow needs.
  2. The endpoint is HTTPS, public to DocuSign, and protected by Connect request verification where available.
  3. The application parses the payload format your configuration actually sends.
  4. Required values are validated; optional values have safe fallbacks.
  5. The Volanea API key is stored in server-side secrets and has never entered client-visible configuration.
  6. A durable unique idempotency record prevents redelivery from creating a second email.
  7. The sender identity is configured and authorized in Volanea before the first production event.
  8. Failures are logged with envelope IDs and alerts, without exposing personal data or credentials.
  9. A test envelope has verified the entire path, including the expected recipient, content, and reply handling.
  10. The team has decided what to do when a completion email cannot be delivered after retries.

Conclusion

To send email from DocuSign with Volanea, use DocuSign Connect as the authoritative envelope-event trigger and a server-side listener as the control point. The listener maps a completed envelope payload into a Volanea email request, keeps the API key private, and treats redelivery as normal behavior rather than an edge case.

That architecture is more work than a hypothetical one-click plugin, but it is also clearer and safer. It keeps document workflow events, email authorization, recipient policy, and audit records in the systems that are responsible for them.

FAQ

Does Volanea have a native DocuSign Marketplace integration?

No. This workflow uses DocuSign Connect to deliver an envelope event to middleware you control, which then calls Volanea’s REST API. There is no native Volanea DocuSign app or Marketplace installation flow in this integration.

What DocuSign event should trigger the email?

For a signed-agreement follow-up, use the envelope completed event. It is a DocuSign envelope status change and is delivered through a Connect configuration or an envelope-level event notification.

Can I send the email directly from DocuSign Connect to Volanea?

Not as a useful direct integration. Connect sends its own event payload to a listener URL, while Volanea expects an email-send request with its own authorization and message fields. Middleware performs the necessary verification, mapping, and duplicate protection.

Why did two completion emails send?

The most likely cause is webhook redelivery after a timeout or failed response. Store a durable idempotency key based on the envelope ID, final status, and configuration context before or while dispatching the email.

Why is a signer or custom field missing from the payload?

Connect payload content depends on your event-data settings, the envelope data itself, and what features are available in the relevant DocuSign configuration. Validate fields defensively and retrieve additional envelope data through the DocuSign API when your workflow requires it.