How to Send Email from Rebrandly with Volanea

Rebrandly can notify your application when link data changes, and that event can become a useful email trigger. This guide shows how to send email from Rebrandly with Volanea through a secure webhook-to-middleware flow rather than relying on a nonexistent native Rebrandly app or marketplace plugin.

The important architectural point is simple: Rebrandly emits an outbound HTTP webhook, your server validates and translates that event, and your server calls Volanea’s email API. Keeping a small middleware layer between the two services protects the Volanea API key, gives you control over recipients and templates, and makes duplicate prevention possible when webhook deliveries are retried.

What this integration does

Rebrandly is a branded-link management platform. A link record contains useful operational data such as its short URL, destination URL, title, domain, tags, and status. When a link is created or updated, that change can matter to people outside the link-management workflow:

• A marketing operations team may need an approval or publication notification when a campaign link is created.
• A customer-success team may need an alert when a customer-facing destination changes.
• A compliance team may need a record when a tracked link is edited.
• A product team may want to email the owner when a link reaches a particular workflow condition established in its own system.

The trigger starts with a Rebrandly webhook event, not with a native Volanea integration. Rebrandly sends an HTTP request to a callback URL you control. That callback should not directly trust the event or blindly turn every delivery into an email. It should validate the request, determine whether the event is relevant, derive an approved recipient, and submit a transactional message through Volanea.

This is a good fit for notifications and operational email. It is not a substitute for consent collection, unsubscribe management, segmentation, and other campaign-program responsibilities. If an event results in promotional messaging, make sure the audience has the appropriate permission and that your sending workflow includes the required preference and compliance handling.

The Rebrandly trigger: a link event

The concrete Rebrandly object in this flow is a link. Configure a Rebrandly webhook for the link event you want to observe—typically a link creation event for “a new branded link is ready” messages, or a link update event when destination, title, tags, or status changes.

A link-created event is usually the cleanest starting point because it has an unambiguous business meaning. An update event needs more care: a link can be updated for many reasons, and a webhook payload may represent the current link state rather than a field-by-field explanation of every change. If you only care about destination changes, store the previous destination in your application and compare it with the incoming value.

Choose one event with one email purpose

Before adding a webhook destination, write the notification rule in a sentence. For example:

When a Rebrandly link is created with the launch-notification tag, send the link owner an internal confirmation email.

That rule has four useful properties. It names the event, identifies a filter, identifies a recipient source, and defines the message’s purpose. A vague rule such as “email somebody when links change” is much more likely to produce noise, accidental sends, and confusing ownership decisions.

Do not assume a Rebrandly link object contains an email address for a recipient. Link data is primarily link metadata. In most implementations, the recipient belongs in your own application database, CRM, internal directory, or a controlled environment variable used only for an internal alert address. A destination URL is never an email recipient.

Inspect an actual delivery before finalizing mappings

Webhook schemas can evolve, and available event types and settings can depend on a Rebrandly account or plan. Create a test link and capture a real webhook delivery at your endpoint or a request-inspection service before making this production logic authoritative. In particular, inspect whether the event uses a top-level event name and a nested link object, and whether fields such as tags, title, and domain are present for the event you selected.

The code below uses a normalized webhook envelope in which type identifies the event and data contains the link. If your captured Rebrandly delivery uses a different envelope, adjust the small normalization block only; do not change the downstream email logic until you understand the payload.

The recommended architecture

A direct browser-to-email-API request is the wrong design. Instead, use this sequence:

1. A user or system creates or updates a link in Rebrandly.
2. Rebrandly posts the link event to an HTTPS endpoint operated by you.
3. Your endpoint verifies the webhook according to the authentication mechanism configured for that endpoint.
4. Your code filters the event and checks an idempotency store.
5. Your code looks up an approved email recipient from your system of record.
6. Your code calls Volanea’s REST email endpoint from the server.
7. Your code records the delivery key and returns a successful HTTP response to Rebrandly.

This architecture keeps responsibilities separate. Rebrandly remains the system that reports link activity. Your middleware owns business rules and recipient authorization. Volanea owns message submission and email infrastructure.

A lightweight serverless function is enough for many teams. Cloudflare Workers, AWS Lambda, Vercel Functions, a small Express service, or a queue consumer can all work. The best choice is the one that can safely store secrets, expose HTTPS, persist idempotency keys, and provide logs your team can investigate.

Configure the outbound webhook in Rebrandly

In Rebrandly, add a webhook destination using the webhook configuration available to your account and point it at a publicly reachable HTTPS URL, such as:

https://automation.example.com/webhooks/rebrandly/link-events

Select the link-created event first. Keep the initial configuration narrow. A single known event is easier to test than several events sent to the same endpoint, especially when each event requires a different recipient rule.

Use a separate endpoint or an explicit environment marker for test and production systems. For example:

https://staging-automation.example.com/webhooks/rebrandly/link-events
https://automation.example.com/webhooks/rebrandly/link-events

Never point production Rebrandly events at an endpoint that uses a test Volanea key or a sandbox-only sender domain. The integration may appear healthy because the HTTP responses are successful while the messages are not reaching the intended environment.

Treat the callback URL as sensitive operational infrastructure

A callback URL is not itself a sufficient authentication control. Someone who discovers it may attempt to post forged events. Protect it with the webhook authentication option Rebrandly provides for your configuration, such as a configured secret or authorization value, and verify that value server-side. If your Rebrandly webhook setup does not provide signed requests, place a secret in a request header or query parameter only as a compensating control, use TLS, rotate it, and reject requests that do not match.

Do not use IP allowlisting as the only control unless Rebrandly documents stable delivery IP ranges and your network team can maintain the list. Signature or secret verification plus application-level validation is generally more resilient than an assumption about the sender’s network address.

Map a Rebrandly link payload into an email

A representative link record contains values such as an ID, title, short URL, destination, domain name, tags, status, and timestamps. The fields that belong in an email are presentation values; the fields that belong in your idempotency store are stable identifiers.

Here is a practical mapping for a link-created notification:

Avoid inserting untrusted link data into raw HTML without escaping it. A link title or destination can contain characters that break markup. Build HTML with an escaping function, or use a template engine that escapes variables by default. The example below escapes the values that are displayed in HTML.

Working server-side example

The following Node.js example shows the full hop: accept a Rebrandly-style link event, filter on a tag, look up the recipient, deduplicate the event, and submit the mapped message to Volanea. Confirm the current endpoint and request schema in the Volanea email API reference and setup guides before deploying, because API versions and supported message fields should be treated as the source of truth.

import express from "express";

const app = express();
app.use(express.json({ type: "application/json" }));

const VOLANEA_API_KEY = process.env.VOLANEA_API_KEY;
const REBRANDLY_WEBHOOK_SECRET = process.env.REBRANDLY_WEBHOOK_SECRET;
const FROM_EMAIL = "Link Operations <links@updates.example.com>";

// Replace these with durable storage in production: Redis, Postgres, DynamoDB, etc.
const processed = new Set();

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

async function getApprovedRecipientForLink(link) {
  // Do not derive a recipient from link.destination or other public link data.
  // This is where your database/CRM lookup belongs.
  if ((link.tags || []).includes("launch-notification")) {
    return "marketing-ops@example.com";
  }
  return null;
}

app.post("/webhooks/rebrandly/link-events", async (req, res) => {
  // Use the request header/verification method configured in Rebrandly.
  // Header name is intentionally an application choice here; configure both sides alike.
  if (req.get("x-webhook-secret") !== REBRANDLY_WEBHOOK_SECRET) {
    return res.status(401).json({ error: "Unauthorized webhook" });
  }

  // Normalize the captured webhook format here if necessary.
  const eventType = req.body.type;
  const link = req.body.data;

  if (eventType !== "link.created" || !link?.id) {
    return res.status(204).end(); // Event is valid but irrelevant to this workflow.
  }

  const recipient = await getApprovedRecipientForLink(link);
  if (!recipient) {
    return res.status(204).end();
  }

  // A stable event key makes webhook retries safe.
  const eventKey = `rebrandly:link.created:${link.id}`;
  if (processed.has(eventKey)) {
    return res.status(200).json({ duplicate: true });
  }

  const title = link.title || "Untitled branded link";
  const shortUrl = link.shortUrl || "(short URL unavailable)";
  const destination = link.destination || "(destination unavailable)";
  const domain = link.domainName || "your branded domain";

  const emailPayload = {
    from: FROM_EMAIL,
    to: [recipient],
    subject: `New Rebrandly link on ${domain}: ${title}`,
    html: `
      <h1>New branded link created</h1>
      <p><strong>Title:</strong> ${escapeHtml(title)}</p>
      <p><strong>Short URL:</strong> <a href="${escapeHtml(shortUrl)}">${escapeHtml(shortUrl)}</a></p>
      <p><strong>Destination:</strong> ${escapeHtml(destination)}</p>
      <p><strong>Link ID:</strong> ${escapeHtml(link.id)}</p>
    `,
    text: [
      "New branded link created",
      `Title: ${title}`,
      `Short URL: ${shortUrl}`,
      `Destination: ${destination}`,
      `Link ID: ${link.id}`
    ].join("\n")
  };

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

  if (!response.ok) {
    const detail = await response.text();
    console.error("Volanea submission failed", response.status, detail);
    // A 5xx response tells the webhook sender that this attempt did not complete.
    return res.status(502).json({ error: "Email submission failed" });
  }

  processed.add(eventKey);
  return res.status(200).json({ accepted: true });
});

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

The important field mapping is explicit: link.title becomes the subject context, link.shortUrl and link.destination become message content, and link.id becomes the stable event identity. Replace the in-memory Set before production. It disappears when a process restarts, does not coordinate across multiple instances, and cannot protect against duplicates over time.

Store the Volanea API key only on the server

The Volanea API key belongs in the secret manager or encrypted environment-variable facility of the service receiving the Rebrandly webhook. In the example, that is VOLANEA_API_KEY. It must not be embedded in browser JavaScript, a public static-site configuration file, a mobile application, a URL, a Git repository, or a Rebrandly link’s metadata.

Rebrandly’s side of this integration should contain only the callback URL and the webhook-authentication material needed to reach your middleware. The middleware is the trust boundary that holds the Volanea credential. A webhook can be observed by systems you do not control along its delivery path; an email API key grants the ability to send as your account and is far more sensitive.

Practical secret-management rules

Use separate Volanea keys for separate environments where possible, and give each integration a recognizable name in your internal secret inventory. Rotate the key if it is exposed, when a maintainer leaves, or on a planned cadence that your deployment process can handle.

Also keep a separate Rebrandly webhook secret. Reusing the Volanea key as the incoming webhook secret is poor practice: it turns an inbound-authentication leak into an outbound-email-account compromise. Two secrets let you rotate and scope the risks independently.

Use a verified sender identity that belongs to your organization. A technically successful API response does not guarantee strong inbox placement; sender-domain authentication, sensible content, recipient engagement, and complaint control all affect deliverability.

Add recipient controls before you automate sends

The biggest integration mistake is treating a newly created link as permission to email an arbitrary address. A Rebrandly event says something happened to a link. It does not establish that a person wants mail, that the person owns the destination domain, or that the event should be externally visible.

For internal notifications, use a fixed team address or a directory lookup keyed by an approved owner ID that your own application controls. For customer messages, look up a recipient only from a consent-aware database and make the trigger conditional on the customer’s chosen notification preference.

A useful decision table is:

• Internal operational notice: send to a fixed internal alias or authenticated employee directory record.
• Customer account notification: send only when the customer account maps to the link and the notification is part of the service relationship.
• Marketing announcement: do not send solely because a link was created; route through your consent-aware campaign workflow.
• Security or compliance alert: send to a controlled role mailbox and retain an audit log of the event and message identifier.

Validate addresses before accepting them into your own recipient store. For one-off list hygiene or signup validation, use an email address verification tool, but do not confuse address validity with consent or deliverability guarantees.

When this breaks: failures specific to the webhook hop

Every event-driven email integration needs a failure plan. The tricky issues occur between Rebrandly’s delivery attempt and your middleware’s final response, not only inside the email API call.

Rebrandly retries can create duplicate sends

Webhook providers commonly retry when they cannot obtain a successful response. A timeout can produce the most confusing version of this problem: your middleware may submit the email successfully, then lose the connection or fail before responding to Rebrandly. Rebrandly sees no success and retries the webhook. Without idempotency, the recipient receives the same notification twice.

Use a durable idempotency record keyed by the event type and link ID, such as rebrandly:link.created:<link-id>. For update events, a link ID alone is not enough because legitimate later updates should be processed. Include a stable event-delivery ID if Rebrandly supplies one; otherwise include a version, timestamp, or content hash after understanding the semantics of the payload.

Create the idempotency record atomically. In a relational database, use a unique constraint. In Redis, use SET key value NX with an appropriate expiry. Do not implement it as “read, then write” in two separate non-atomic operations, because concurrent retries can both pass the read check.

Webhook timeouts can make a healthy integration look broken

Your endpoint should return promptly. Calling a downstream email API, a CRM, and several databases before responding increases timeout risk. For higher-volume or business-critical workflows, acknowledge a validated event after durably queueing it, then have a worker perform the Volanea API call.

A queue changes failure handling for the better. The webhook endpoint’s job becomes validation and durable acceptance. The worker owns retries to Volanea, exponential backoff, dead-letter handling, and the final idempotency state. This also prevents a temporary email API outage from tying up incoming webhook connections.

Do not return a success response before you have durably recorded enough data to process the event. Otherwise, a crash after the acknowledgment loses the notification permanently because the sender has no reason to retry.

Payload fields may be absent

Not every link event necessarily supplies every optional field you want, and webhook features or payload details may vary by account configuration and plan. title may be empty, tags may be absent, and a payload may not include the owner information your business rule requires. Build explicit fallback behavior rather than generating subjects such as “undefined” or sending to a guessed recipient.

The example uses safe fallbacks for display fields and refuses to send without a recipient produced by the approved lookup. In production, log a structured “skipped due to missing recipient” event with the link ID and event type. That gives your team an actionable record without exposing API credentials or unnecessary personal data in logs.

Sender, recipient, and API failures need different responses

An invalid webhook secret is an authentication failure: return a 401 or 403 and investigate the configuration. A malformed payload is a validation failure: return a 400 if retries will not help. A temporary database or Volanea issue is a transient failure: return a 5xx or queue the item for retry, while relying on idempotency to avoid duplicates.

For a Volanea 4xx response, inspect the response and correct the request, sender identity, or recipient data. Repeating an invalid payload usually will not fix it. For 5xx responses or network failures, apply bounded exponential backoff and alert when retries are exhausted.

Test the flow without emailing real customers

Start with a test recipient controlled by your team and a verified sending domain. Create a test link with a distinct title and a tag that uniquely identifies the test, such as integration-test. Confirm each stage independently:

1. Rebrandly records the webhook delivery and receives a successful response.
2. Your middleware logs the normalized event type and link ID without logging secrets.
3. Your idempotency storage records the event key once.
4. Volanea accepts the message submission.
5. The recipient receives a readable email with the expected short URL and destination.
6. Repeating the same webhook does not create a second send.

Then deliberately test failures. Send a request with the wrong incoming secret and ensure it is rejected. Remove the title and ensure the fallback is useful. Make the Volanea call fail in a staging environment and ensure the response or queue behavior matches your retry design. Finally, replay an identical event twice and verify that the first submission is accepted while the second is classified as a duplicate.

Do not use a real customer destination URL as an excuse to test customer email. The email target and the link target are separate risks. Test each with controlled resources.

Alternatives when direct webhooks are not available to your account

Webhook availability, event options, and administrative access can vary. If your Rebrandly account cannot configure an outbound webhook for the needed link event, do not pretend there is a native Volanea app to install. Use an automation platform or your own scheduled integration instead.

A middleware route through Zapier or Make can receive a supported Rebrandly trigger, apply simple filters, and call a custom webhook endpoint that you operate. The safer pattern is still to have that endpoint hold the Volanea key, rather than placing a long-lived email credential in a broadly accessible automation step.

For a small internal workflow, an automation platform may be enough. For a high-volume or customer-facing workflow, own the middleware and queue. You gain version-controlled code, explicit validation, durable idempotency, better secret handling, and clearer audit trails.

Operational and deliverability considerations

This integration is only as good as the message policy behind it. A flood of low-value “link updated” mail trains recipients to ignore important notices and can harm engagement signals. Prefer useful, actionable messages: what changed, which link is affected, who should act, and where they can review the record.

Keep transactional notifications recognizable. Use a consistent sender name, an authenticated domain, and a subject that describes the actual event. If the notification is internal, include both the branded short URL and destination so a reviewer can spot an unexpected redirect without having to click first.

Watch submission outcomes, bounces, complaints, and recipient feedback. A successful send request means the provider accepted the message for processing; it is not proof of inbox placement or reader action. If you expect meaningful volume, review your sending plan and operational needs before launch, including transactional email pricing and sending costs.

A production checklist

Before enabling the workflow for real recipients, verify the following:

• The configured Rebrandly event is specifically the link event your rule requires.
• A captured real payload matches the normalization code and field mapping.
• The callback endpoint is HTTPS and verifies a distinct incoming webhook secret or signature.
• The Volanea API key exists only in server-side secret storage.
• The sender identity is verified and appropriate for the notification type.
• Recipient selection comes from an approved system of record, not link metadata.
• Idempotency is durable, atomic, and tested with duplicate deliveries.
• Missing optional fields produce safe fallbacks or a deliberate skip.
• Volanea failures, database failures, and malformed webhook payloads have separate handling.
• Logs retain useful event IDs and response codes without exposing keys or unnecessary personal data.

The result is intentionally modest: Rebrandly reports a link event, your application decides whether it merits an email, and Volanea sends a clear transactional notification. That separation is what makes the integration dependable as event volume and business rules grow.

FAQ

Can I install a native Volanea app in Rebrandly?

No. This workflow uses Rebrandly’s outbound webhook capability and a server-side middleware endpoint you operate. There is no native Rebrandly marketplace installation assumed here.

Which Rebrandly event should trigger the first email?

Start with a link-created event. It is easier to make idempotent and easier to explain to recipients than a broad link-updated event. Add update handling only after defining exactly which changes require a notification.

Can I put my Volanea API key in a Rebrandly webhook URL or browser app?

No. Store the key only in server-side secret storage used by your middleware. A URL, client-side application, or public configuration can expose a credential that permits unauthorized email sending.

How do I prevent duplicate emails after a webhook retry?

Use a durable, atomic idempotency key based on the event type and stable link identity, and pass the same key to Volanea if the API supports idempotency headers. Record successful processing before treating later deliveries as duplicates.

What if a Rebrandly payload does not include a title or tags?

Use a safe display fallback for optional content and skip the send when required business data—especially an approved recipient—is missing. Log the skip with the link ID so the workflow can be corrected without creating misleading email.