How to Send Email From Outreach With Volanea

Send email from Outreach with Volanea by subscribing to an Outreach webhook, receiving its JSON:API event on your server, and sending the resulting message through Volanea’s REST API. There is no native Volanea app or Outreach Marketplace installation flow, so the reliable implementation is a direct webhook-to-server-to-email integration.

What this Outreach and Volanea integration does

Outreach is built around sales-engagement records such as prospects, accounts, tasks, mailings, opportunities, and sequence states. Volanea is the delivery layer in this setup: it sends transactional or operational email when an event in Outreach tells your system that a prospect-related change occurred.

That division is useful when the message should not be a normal sales sequence email sent from an individual rep mailbox. Examples include a branded confirmation after a prospect record enters Outreach, an internal routing alert when a prospect is created, a request for missing information, a compliance notice, or a notification generated by a custom workflow outside the rep’s mailbox.

The important architectural point is that this is not a browser integration and not a client-side form post. Outreach sends an event to an HTTPS endpoint you control. That endpoint validates and interprets the event, optionally retrieves additional data from Outreach, and calls Volanea with a server-held API key.

A practical flow looks like this:

1. An Outreach object changes, such as an emailAddress being created or a prospect being updated.
2. An Outreach webhook posts a JSON:API-style payload to your HTTPS endpoint.
3. Your relay identifies whether the event qualifies for an email.
4. The relay builds an email payload from the webhook fields and, where necessary, performs a read from the Outreach API for complete prospect details.
5. The relay calls POST /v1/send on Volanea with an Idempotency-Key.
6. Volanea accepts the send, applies suppression and contact checks, renders the message content, and dispatches it through the configured sending domain.

This pattern keeps roles clear. Outreach remains the system that detects the sales event. Your service owns policy, field mapping, consent checks, and duplicate handling. Volanea owns the actual email API call and delivery lifecycle.

The real trigger: an Outreach webhook event

For a direct integration, use Outreach’s platform webhooks rather than an imagined “send HTTP request” action inside the normal Outreach trigger builder. Outreach documents webhooks as API resources: you create a webhook record with an HTTPS URL plus the resource and action that should cause delivery.

For a first implementation, use the emailAddress.created event. Outreach lists emailAddress among supported webhook resources and supports the created, updated, and destroyed actions for it. This is a more precise trigger than “prospect created” when your goal is to send an email to a newly available address, because a prospect record can exist before an address is attached or can later receive an additional address.

The underlying trigger is therefore:

• Outreach resource: emailAddress
• Outreach action: created
• Webhook event name: emailAddress.created
• Destination: your server-side endpoint, for example https://integrations.example.com/webhooks/outreach

Do not confuse this API webhook with the Outreach Admin trigger interface. Outreach Admin triggers can automate actions inside Outreach around events such as a Prospect being Updated or Created, but the public webhook facility is what sends an outbound JSON request to an HTTPS URL. They solve related but different problems.

Create the Outreach webhook subscription

Webhook registration is performed through the Outreach API. Outreach’s documented pattern is a POST to /api/v2/webhooks using a JSON:API document. A request for the event used in this guide follows this structure:

{
  "data": {
    "type": "webhook",
    "attributes": {
      "action": "created",
      "resource": "emailAddress",
      "url": "https://integrations.example.com/webhooks/outreach"
    }
  }
}

Creating and reading Outreach resources requires OAuth 2.0. Your integration therefore needs an Outreach application, an authorization flow, and a server-side store for the resulting OAuth tokens. Request only the scopes required for the webhook resources and any prospect or email-address reads your relay performs.

The webhook creation response includes metadata such as whether the subscription is active, the selected resource and action, the destination URL, a webhook secret, and its payload version. Store the webhook ID and operational details in your integration database. The webhook ID is useful when you need to inspect, replace, or remove a subscription without creating a second subscription by mistake.

Why emailAddress.created is a sensible default

A created email-address event is not the only option. You might instead listen to prospect.updated and send only when a defined custom field changes, or listen to opportunity.updated to notify an owner about a stage change. But each broader resource event creates more filtering work and more risk of accidentally mailing someone when an unrelated attribute changes.

Start narrow. With emailAddress.created, your relay can require all of the following before it sends:

• The webhook’s meta.eventName equals emailAddress.created.
• The payload contains a syntactically valid email address.
• The event is associated with an intended source or qualifying business rule.
• The recipient has a valid lawful or operational reason to receive the message.
• A stable idempotency key has not already been accepted for this event.

This does not mean every new address deserves an immediate marketing email. A created record is a technical event, not evidence of marketing consent. Use it for messages the recipient expects, or route the event into a review, consent, or preference process first.

Understand the Outreach webhook payload before mapping it

Outreach webhook deliveries use a JSON:API-style envelope. For version 1, the payload has a top-level data object for the resource and a meta object describing the event. Outreach documents that created and updated events contain only created or changed attributes; deleted events contain the last known attributes and relationships.

That last point has major implementation consequences. Treat the payload as an event notification, not as a durable complete customer profile. If your subject line requires a full name, account information, territory, owner, or a custom qualification field, the event alone may not contain all of those values. Fetch the current record from Outreach before sending, or design a message that safely works with the fields guaranteed by your event.

A representative event envelope has this shape:

{
  "data": {
    "type": "emailAddress",
    "id": "987654",
    "attributes": {
      "email": "alex@example.com"
    }
  },
  "meta": {
    "deliveredAt": "2026-10-10T15:30:01.000Z",
    "eventName": "emailAddress.created"
  }
}

The resource ID and event name are the most valuable fields for reliable processing. The ID represents the Outreach resource that changed. The event name identifies the transition. deliveredAt is useful for logging, but it should not be your uniqueness key: a retry can have a different delivery time while representing the same logical event.

Field mapping for this implementation

The relay in the next section makes the mapping explicit instead of assuming that Outreach and Volanea use identical field names:

The key design decision is that the webhook does not select the sender address, create arbitrary HTML, or supply API credentials. Those are all server-owned choices. Letting webhook data control them would create an avoidable security and deliverability problem.

Build a secure server-side relay

The relay can run as an Express service, serverless function, queue worker fronted by an HTTP handler, or any equivalent server-side environment. It needs two trust boundaries:

1. Inbound: accept only expected Outreach webhook traffic at a dedicated endpoint, validate the event shape, and record enough data to investigate failures.
2. Outbound: hold the Volanea secret key in server-side secret storage and use it only when the event has passed your rules.

The following Node.js example uses Express and native fetch. It maps an emailAddress.created event to a one-recipient transactional email through Volanea. It deliberately makes content server-defined and derives the idempotency key from the immutable Outreach resource event.

import express from "express";

const app = express();
app.use(express.json({ type: ["application/json", "application/vnd.api+json"] }));

const {
  VOLANEA_API_KEY,
  VOLANEA_FROM_EMAIL,
  OUTREACH_WEBHOOK_PATH_TOKEN
} = process.env;

if (!VOLANEA_API_KEY || !VOLANEA_FROM_EMAIL || !OUTREACH_WEBHOOK_PATH_TOKEN) {
  throw new Error("Missing required server-side environment variables");
}

app.post(`/webhooks/outreach/${OUTREACH_WEBHOOK_PATH_TOKEN}`, async (req, res) => {
  const event = req.body;
  const emailAddress = event?.data;
  const meta = event?.meta;

  // Concrete Outreach trigger validation.
  if (
    emailAddress?.type !== "emailAddress" ||
    meta?.eventName !== "emailAddress.created" ||
    !emailAddress?.id
  ) {
    return res.status(204).end(); // Ignore events this endpoint does not handle.
  }

  // Field mapping: Outreach data.attributes.email -> Volanea to.
  const recipient = String(emailAddress?.attributes?.email || "").trim().toLowerCase();
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(recipient)) {
    console.error("Outreach emailAddress.created event has no usable email", {
      outreachEmailAddressId: emailAddress.id,
      eventName: meta.eventName
    });
    return res.status(204).end();
  }

  // One stable key per logical Outreach event, reused if Outreach retries delivery.
  const idempotencyKey = `outreach-email-address-created-${emailAddress.id}`;

  const volaneaPayload = {
    from: VOLANEA_FROM_EMAIL,
    to: recipient,
    subject: "Thanks — we received your details",
    text: "Thanks — we received your details. A member of our team will be in touch.",
    html: "<p>Thanks — we received your details.</p><p>A member of our team will be in touch.</p>",
    headers: {
      "X-Outreach-Email-Address-Id": String(emailAddress.id),
      "X-Outreach-Event": meta.eventName,
      "X-Outreach-Delivered-At": meta.deliveredAt || ""
    }
  };

  try {
    const response = await fetch("https://api.volanea.com/v1/send", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey
      },
      body: JSON.stringify(volaneaPayload)
    });

    const responseBody = await response.text();
    if (!response.ok) {
      console.error("Volanea send failed", {
        status: response.status,
        outreachEmailAddressId: emailAddress.id,
        responseBody
      });
      return res.status(502).json({ error: "Email provider rejected the send" });
    }

    console.info("Volanea send accepted", {
      outreachEmailAddressId: emailAddress.id,
      idempotencyKey,
      responseBody
    });

    return res.status(202).json({ accepted: true });
  } catch (error) {
    console.error("Volanea request could not be completed", {
      outreachEmailAddressId: emailAddress.id,
      error: error instanceof Error ? error.message : String(error)
    });
    return res.status(503).json({ error: "Temporary delivery relay failure" });
  }
});

app.listen(3000, () => console.log("Outreach relay listening on port 3000"));

Before deploying, test with a Volanea test key if your environment supports one, then send only to controlled inboxes. Confirm that the sending domain has been added and verified in Volanea before assuming a rejected send is caused by Outreach. The Volanea API reference and setup guides are the right place to verify the current request schema, domain configuration requirements, and response details before promoting a relay to production.

Keep the Volanea API key out of Outreach and out of the browser

The Volanea API key belongs in the relay’s secret manager or server-side environment configuration. It does not belong in an Outreach prospect custom field, a task note, an Outreach trigger label, a webhook URL query parameter, a client extension configuration page exposed to users, or browser JavaScript.

There is an important distinction here: Outreach needs to know the destination URL for its webhook. It does not need to know the Volanea API key. Your endpoint is the boundary between the two platforms, and your endpoint makes the authenticated Volanea request.

Use a secret store provided by your deployment platform, such as a cloud secret manager, encrypted environment variables, or an equivalent server-side vault. Give the runtime identity permission to read only the secret it needs. Rotate the Volanea key without changing the Outreach webhook URL when possible, then deploy the new secret and revoke the old credential after confirming healthy sends.

Why client-visible configuration is unsafe

A browser must be assumed observable by the person using it. Any API key embedded in frontend JavaScript, a mobile app bundle, a publicly readable configuration endpoint, or an unauthenticated low-code page can be extracted. Once exposed, a sending API key can be abused to send email under your verified domain, consume quota, damage reputation, or create an incident that is much harder to untangle than a bad template.

The same rule applies to a direct call from Outreach UI code. Even if a custom interface seems internal, it is still client-side code unless the call is made by a trusted server component. The browser should call your application, and your application should decide whether to invoke Volanea.

Protect the inbound webhook route

The opaque path token in the code is a baseline control, not a replacement for a documented signature-verification scheme. Generate a long random value, keep it in secret storage, and do not place it in logs. Use HTTPS exclusively.

Also put operational controls around the endpoint:

• Restrict the route to POST and reject unexpected content types.
• Cap request-body size to reduce abuse.
• Validate data.type, data.id, and meta.eventName before doing provider work.
• Log event identifiers and outcomes, but avoid logging message bodies or credentials.
• Keep an allowlist of events your relay actually supports.
• Return quickly after durable acceptance if you later add a queue.

If your Outreach webhook configuration and current platform documentation provide a supported signing-verification method for your subscription, implement it against the raw request body before JSON parsing. Do not invent a header name or HMAC algorithm based on another vendor’s webhook conventions.

Handle partial data with an Outreach API lookup

The direct payload route above works for a generic email where the new address itself is sufficient. In most production workflows, you will want richer personalization: the prospect’s first name, last name, company, owner, stage, custom qualification field, or connected account.

Because Outreach says create and update webhooks carry created or changed attributes, retrieve the current prospect or related resource through the Outreach API when the message depends on fields not guaranteed in the event. Outreach’s API uses OAuth 2.0 and JSON:API conventions; its requests require application/vnd.api+json content negotiation.

A sensible approach is to maintain a mapping from an Outreach email-address record to its prospect, then retrieve the prospect server-side using a token with the minimum read scope. If the exact relationship is not included in your webhook version, query the relevant resource according to the current Outreach API schema rather than guessing field names. Organizations can also have custom Prospect fields, and those fields must be read according to the schema for that organization.

Do not turn an incomplete lookup into a broken email. Use progressive fallbacks:

1. If a verified first name exists, use it in the greeting.
2. If no first name exists, use a neutral greeting such as “Hello.”
3. If the recipient email is missing or invalid, do not send; log the event for review.
4. If a qualifying custom field is unavailable, route to a retry or manual-review queue rather than treating missing as approval.

This protects both customer experience and data quality. It is better to delay a personalized confirmation than to send “Hi undefined” or to mail an address whose source is unclear.

Use idempotency because webhook delivery is not exactly once

A webhook relay has at least two separate network hops: Outreach to your server and your server to Volanea. A timeout or interrupted connection can leave either sender unsure whether the receiver actually completed the work. Retrying is correct behavior, but a retry without a stable identifier can send duplicate email.

Volanea’s send endpoint supports the Idempotency-Key header. Build its value from the specific logical event, not from the current timestamp and not from a random UUID generated inside the handler on every request. In this guide, the key is based on the event type and the Outreach email-address resource ID:

outreach-email-address-created-987654

If Outreach sends the same event again, your relay produces the same key and the same Volanea request. If the first request reached Volanea but the response was lost, repeating it with the same key lets the provider treat it as a replay instead of a second new send.

Do not reuse that key for a materially different message. A changed subject, recipient, sender, or body is a different logical operation and should use a different key. If you later send a second legitimate email for the same address, key it from the distinct event or business action—for example, outreach-prospect-stage-changed-{prospectId}-{stageTransitionId}.

For an integration that can generate high volume, persist event processing in a database as well. Store the event identifier, generated idempotency key, recipient, event name, provider response status, attempt count, and timestamps. That local ledger gives your team an audit trail even after external request logs rotate.

When this breaks

This integration crosses API, webhook, delivery, and data-model boundaries. The most common failures are not mysterious; they are predictable effects of retries, partial event payloads, expired authorization, and changing configuration.

Outreach retries cause duplicate-looking sends

A response can time out after Volanea accepted the email but before your relay replied to Outreach. Outreach may deliver the webhook again. If your code creates a new send with a newly generated key every time, recipients can receive duplicates.

Fix: derive the Volanea Idempotency-Key deterministically from the Outreach event’s stable identity and preserve the same email payload for retry attempts. Keep a local event ledger as a second layer of duplicate protection. Review duplicate incidents by comparing the Outreach resource ID, the key, and the Volanea response.

The webhook request times out

Your endpoint may spend too long calling Outreach for enrichment, rendering a complex template, waiting for a database lock, or waiting for Volanea. A slow synchronous design increases the chance that the sender concludes delivery failed.

Fix: make the HTTP endpoint small and durable. Validate the event, write a job record keyed by the event identity, enqueue it, then return a success response promptly. A worker can perform enrichment and call Volanea afterward. The worker must still use the same idempotency key, because a queue can also retry jobs.

Payload fields are missing

An event may not include the full profile fields your template expects. This is especially likely for update events because Outreach documents that they contain changed attributes rather than a full resource snapshot. Custom fields may also differ across Outreach organizations or not be present in the API scope available to your integration.

Fix: never assume every prospect has every field. Validate the webhook’s required minimum, retrieve additional data with the Outreach API when necessary, and use explicit fallbacks. Keep qualification policy in code or configuration that is versioned and tested, rather than embedding it in a fragile subject-line expression.

An Outreach feature or API permission is unavailable

Your Outreach environment must have the necessary API access for a custom OAuth application and webhook subscription. If your account cannot create or authorize the required integration, there is no honest direct-webhook workaround from a standard trigger screen.

Fix: confirm API access and scopes with your Outreach administrator before building. If direct API/webhook access is unavailable in your environment, use middleware such as Zapier or Make only if that connector is available to your account and can safely call a server-owned relay. Do not paste a Volanea secret into a client-visible automation field; have the automation call your relay, and have the relay call Volanea.

The Volanea request is rejected

Typical provider-side problems include an invalid API key, an unverified or unauthorized from address, malformed request data, or a recipient that is suppressed or unsubscribed according to the send policy.

Fix: log the Volanea response status and request correlation data, without logging secrets. Verify the domain and sender before production traffic. Treat a suppression result as a policy outcome, not as a reason to retry repeatedly. If the address quality itself is uncertain, check it before adding it to an outbound process with the email address verification tool.

OAuth tokens expire or are revoked

The webhook receiver itself can process the minimal event without an Outreach read token, but personalized enrichment calls require valid OAuth credentials. Expired access tokens, a revoked grant, or insufficient scopes can turn a previously successful workflow into partial sends or failed jobs.

Fix: build token refresh and authorization-failure monitoring before relying on enrichment. Keep refresh tokens encrypted. Alert on repeated 401 or 403 responses, and choose a safe policy: send a non-personalized operational message only when that is appropriate, or hold the job until authorization is repaired.

Choose the right email type and sending policy

A Volanea API connection does not automatically make an Outreach-triggered message appropriate to send. Sales engagement data can include addresses sourced from imports, CRM syncs, enrichment, events, and manual entry. The fact that an address exists is not itself permission to send every category of email.

Classify the message before implementation:

• Operational or transactional: confirmation, security notice, a requested resource, or a service update. These typically use event-specific content and should not be mixed with promotional language.
• Sales sequence communication: one-to-one or sales-assisted outreach that is normally managed through Outreach and the connected rep mailbox.
• Marketing: broad promotional or nurture messaging with separate consent, unsubscribe, segmentation, and frequency rules.
• Internal notification: messages to your team, such as an owner alert about a prospect event. These can often use internal distribution rules instead of prospect-address data.

For messages going to external prospects, keep the message purpose narrow and align the sender identity, reply handling, and preference obligations with that purpose. Do not quietly turn a “we received your details” confirmation into a sales campaign by adding marketing content after the fact.

Test the integration as a delivery system, not just a code snippet

A successful 200 or 202 response from your relay proves only that one layer accepted something. You need tests across the full event path.

A practical test checklist

1. Register the webhook in a non-production Outreach environment or use a tightly controlled test record.
2. Point it to a staging endpoint with a different opaque path token.
3. Create one test email-address record and save the raw webhook envelope after removing personal data.
4. Confirm the handler recognizes emailAddress.created and ignores unexpected events.
5. Confirm the mapping writes the expected recipient, sender, subject, and trace headers.
6. Send to a controlled inbox and inspect the received message, sender domain, text fallback, and headers.
7. Replay the same event payload to prove that the idempotency key prevents a second logical send.
8. Remove the email field from a test payload to prove the handler does not attempt a send.
9. Simulate a Volanea 5xx response and ensure your retry process keeps the same key.
10. Confirm logs let an operator move from Outreach resource ID to your job record and Volanea send outcome.

Test a message with HTML disabled, too. The plain-text text field is not merely a fallback for old clients; it is important for accessibility, diagnostics, and recipient environments that cannot or should not render HTML.

Production architecture for higher-volume workflows

The inline Express example is intentionally readable, but a busy production workflow benefits from an asynchronous architecture. The recommended shape is webhook receiver, durable job store, queue, worker, provider API, and observability.

The receiver should do only identity validation, basic schema validation, deduplication claim, and enqueueing. The worker should retrieve any needed Outreach details, calculate the policy decision, create the fixed Volanea payload, and attempt the send. Both components should record the same correlation fields.

This separates latency from throughput. An outage in Volanea or a slow Outreach lookup no longer keeps inbound webhook connections open for an unpredictable period. It also makes controlled retries, dead-letter handling, alerting, and operator replay possible.

For each job, retain at minimum:

• Outreach webhook resource type and resource ID
• Outreach event name and delivery timestamp
• Internal job ID and state
• Volanea idempotency key
• Recipient address or a privacy-safe hash where appropriate
• Volanea HTTP status and provider message identifier when returned
• Attempt count, next retry time, and final failure reason

The operational result is not simply “an email was sent.” It is a traceable chain showing which Outreach event requested the message, what policy allowed it, whether Volanea accepted it, and what follow-up is required if it did not.

Conclusion

To send email from Outreach with Volanea, use an Outreach API webhook as the outbound event source and a server-side relay as the trusted integration layer. A concrete, low-risk starting point is emailAddress.created: Outreach posts a JSON:API event, your service validates it, maps data.attributes.email into Volanea’s to field, and submits a server-owned message to POST /v1/send.

The implementation succeeds or fails on the details: do not expose the Volanea API key, do not treat partial webhook data as a complete profile, do not use a fresh idempotency key for every retry, and do not assume a technical record-creation event equals consent for every email category. Build a narrow first flow, log every hop, test duplicates deliberately, then expand to richer Outreach events only when the data and policy are clear.

FAQ

Does Volanea have a native Outreach integration?

No. This setup does not use a native Outreach app, Marketplace listing, or one-click plugin. It uses Outreach webhooks, a server-side relay you control, and Volanea’s REST send endpoint.

What Outreach event should start the email?

For a simple recipient-address-driven flow, use the Outreach emailAddress.created webhook event. For workflow-specific messages, use the resource and action that represent the actual business event, then filter and enrich it in your relay.

Where should the Volanea API key be stored?

Store it only in server-side secret management or protected runtime environment variables used by your relay. Outreach receives your webhook destination URL; it should not store the Volanea key for this integration.

How do I prevent duplicate emails when Outreach retries a webhook?

Use a deterministic Idempotency-Key on the Volanea POST /v1/send request, derived from the Outreach event’s stable identity. Reuse that exact key only when retrying the same logical send.

Can I send personalized emails from the webhook payload alone?

Sometimes, but do not assume it. Outreach webhooks for creates and updates can contain only created or changed attributes. Retrieve the current Outreach resource through the API when the email needs fields that are not guaranteed in the event payload.