If you need to send email from Cyfe, the important first step is understanding what Cyfe can actually do. Cyfe can visualize data, accept data through its Push API, and schedule its own dashboard reports, but its documented integration model does not provide an outbound webhook or workflow trigger that can call Volanea when a dashboard value changes.

That means there is no native Cyfe-to-Volanea app, marketplace installation, record-created trigger, form-submitted trigger, or dashboard-stage-changed event to configure. The reliable approach is to trigger Volanea from the application that produces the business event, route that event through a secure server-side endpoint or automation middleware, and optionally push the resulting metric into Cyfe for visibility.

The short answer: Cyfe cannot be the outbound trigger

Cyfe is designed primarily as an all-in-one business dashboard. Its Push API works in one direction: your application sends data into a Cyfe widget. Cyfe documents this as an app event, such as a new signup, causing your app to POST metric data to the API endpoint attached to a Push API widget.

That is the opposite direction from an email automation flow. A Cyfe dashboard does not expose a documented outbound HTTP webhook that can emit a payload when a widget updates, crosses a threshold, receives a Push API value, or is viewed. It also does not provide a documented workflow builder where a dashboard metric can start an HTTP request to an email API.

Cyfe can automatically email dashboard reports through its own Export Dashboard scheduling feature. That feature sends Cyfe reports, however; it is not a hook that hands report data to Volanea, and it does not let you replace Cyfe’s sender with an arbitrary REST API.

So the concrete answer to the trigger question is:

There is no Cyfe record-created, form-submitted, stage-changed, widget-updated, or dashboard-alert webhook trigger for Volanea to receive.
The relevant trigger must be the original event in the system Cyfe is monitoring.
Cyfe should be the reporting destination, not the source of the transactional send.

This distinction prevents a fragile design where a reporting dashboard is incorrectly treated as the system of record for customer communication.

What Cyfe actually sends and receives

Because Cyfe has no documented outbound event webhook for this use case, there is no real Cyfe outbound email-event payload to map into Volanea. Do not invent one, and do not build production logic around scraping dashboard data or browser automation.

The documented Cyfe Push API payload is an inbound request from your application to Cyfe. It contains a required data parameter whose value is a JSON string. The first item in that data is a unique key, commonly a date in YYYYMMDD form for time-series charts. Cyfe also documents optional parameters including onduplicate, color, type, cumulative, average, total, comparison, and reverse.

A representative Push API request from your application to Cyfe looks like this:

const cyfeBody = new URLSearchParams({
  data: JSON.stringify([
    ['Date', 'Emails sent'],
    ['20261003', 1]
  ]),
  onduplicate: 'replace'
});

await fetch(process.env.CYFE_PUSH_API_ENDPOINT, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded'
  },
  body: cyfeBody
});

That request updates a Cyfe chart. It does not cause Cyfe to send an email, and it does not provide recipient names, recipient addresses, message content, consent state, or a stable business-event identifier. Those are all values that must come from the original system: a form backend, CRM, billing product, support tool, ecommerce platform, or your own application.

The recommended architecture for Cyfe and Volanea

The dependable architecture separates communication from observability.

A source application creates the business event, such as a new lead, paid invoice, completed signup, or support ticket update.
The source application sends its event to a secure middleware endpoint that you control, or to an automation platform that supports the source as a trigger.
The middleware validates the event, creates a stable idempotency key, and makes a server-side request to Volanea.
The same middleware optionally pushes a small metric to Cyfe’s Push API, such as one successfully accepted transactional email.
Delivery events, bounces, complaints, and suppression outcomes remain part of your email operations rather than being inferred from a dashboard number.

This is the flow in compact form:

Source event
  -> secure middleware or automation workflow
  -> Volanea POST /v1/send
  -> optional Cyfe Push API metric update

The source event is the true trigger. For example:

A website backend receives a contact-form submission.
A CRM creates a lead.
A payment provider confirms a successful invoice payment.
An application creates a user account.
A support platform changes a ticket to resolved.

In each case, Cyfe can still display counts, conversion metrics, and delivery-health summaries. But the source system owns the event, which makes it the correct place to decide whether an email should be sent.

Choose the source event before you write email code

A transactional email should correspond to a concrete, meaningful event. Before connecting anything to Volanea, write a one-sentence event contract.

For example:

When the application creates a new verified trial account, send one welcome email to that account’s primary email address.

That statement answers several operational questions that a dashboard value cannot answer on its own:

Which application owns the event?
What exact moment counts as completion?
Which field is the authoritative recipient address?
Which event ID can identify retries of the same logical action?
Is the email transactional or marketing?
What should happen if the address is missing, invalid, suppressed, or unsubscribed?

For a transactional message, use a narrow event definition. A dashboard total rising from 99 to 100 is not itself a safe trigger because it contains no customer identity and may reflect a delayed import, duplicate metric update, manual correction, or data refresh.

A source event should have a durable ID. Examples include a user ID plus event type, an order ID, an invoice ID, a ticket ID, or a webhook event ID supplied by the upstream application. That ID becomes the foundation for retry safety.

Working server-side example: source event to Volanea

The example below uses a Cloudflare Worker-style JavaScript endpoint, but the design is portable to Express, Fastify, a serverless function, Rails, Laravel, or any backend runtime. It receives a deliberately small event payload from the source application, validates it, maps fields into Volanea’s email shape, and sends one transactional message through POST /v1/send.

The inbound payload in this example is not a Cyfe payload. Cyfe does not emit this event. It is the payload your source application or source-triggered automation should send to your middleware endpoint.

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

    // Authenticate the source system before processing its event.
    if (request.headers.get('X-Integration-Secret') !== env.INTEGRATION_SECRET) {
      return new Response('Unauthorized', { status: 401 });
    }

    const event = await request.json();

    // Expected source-event payload shape:
    // {
    //   eventId: 'lead_01J...',
    //   type: 'lead.created',
    //   lead: {
    //     email: 'ada@example.com',
    //     firstName: 'Ada',
    //     company: 'Analytical Engines Ltd'
    //   }
    // }
    if (event.type !== 'lead.created') {
      return Response.json({ ignored: true, reason: 'Unsupported event type' });
    }

    const email = event.lead?.email?.trim().toLowerCase();
    const firstName = event.lead?.firstName?.trim() || 'there';

    if (!event.eventId || !email || !email.includes('@')) {
      return Response.json(
        { error: 'eventId and a valid lead.email are required' },
        { status: 400 }
      );
    }

    // Field mapping:
    // event.lead.email     -> to[0].email
    // event.lead.firstName -> to[0].name and message copy
    // event.eventId        -> Idempotency-Key
    const volaneaPayload = {
      from: {
        email: 'hello@your-verified-domain.com',
        name: 'Example Company'
      },
      to: [
        {
          email,
          name: event.lead.firstName || undefined
        }
      ],
      subject: `Thanks for contacting us, ${firstName}`,
      text: `Hi ${firstName},\n\nThanks for getting in touch. We received your request and will reply shortly.\n\nExample Company`,
      html: `<p>Hi ${escapeHtml(firstName)},</p><p>Thanks for getting in touch. We received your request and will reply shortly.</p><p>Example Company</p>`
    };

    const sendResponse = await fetch('https://api.volanea.com/v1/send', {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${env.VOLANEA_API_KEY}`,
        'Content-Type': 'application/json',
        'Idempotency-Key': `lead-created:${event.eventId}`
      },
      body: JSON.stringify(volaneaPayload)
    });

    const sendResult = await sendResponse.json();

    if (!sendResponse.ok) {
      console.error('Volanea send failed', {
        status: sendResponse.status,
        result: sendResult,
        eventId: event.eventId
      });

      return Response.json(
        { error: 'Volanea rejected the send', detail: sendResult },
        { status: 502 }
      );
    }

    // Optional: send an aggregate metric into Cyfe after acceptance.
    // A failed Cyfe metric update must not cause the email to be sent again.
    if (env.CYFE_PUSH_API_ENDPOINT) {
      const today = new Date().toISOString().slice(0, 10).replaceAll('-', '');
      const cyfeBody = new URLSearchParams({
        data: JSON.stringify([
          ['Date', 'Transactional emails accepted'],
          [today, 1]
        ]),
        onduplicate: 'replace'
      });

      const cyfeResponse = await fetch(env.CYFE_PUSH_API_ENDPOINT, {
        method: 'POST',
        headers: {
          'Content-Type': 'application/x-www-form-urlencoded'
        },
        body: cyfeBody
      });

      if (!cyfeResponse.ok) {
        console.error('Cyfe metric update failed', {
          status: cyfeResponse.status,
          eventId: event.eventId
        });
      }
    }

    return Response.json({ accepted: true, result: sendResult });
  }
};

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

The Volanea request uses a secret API key, JSON content, the documented API base URL, and an Idempotency-Key header. The endpoint accepts a single message for one recipient or up to 50 recipients, but a one-event-to-one-recipient pattern is generally safer for transactional notifications. It provides a clean audit trail and avoids exposing recipients to one another.

For the full endpoint surface, authentication guidance, and current request schema, consult the Volanea REST API reference before deploying changes.

Field mapping: keep the business event separate from the email

A good integration does not blindly forward an upstream payload to an email API. It maps the minimum necessary fields into a message that your backend controls.

Here is the mapping in the working example:

Source event field	Volanea field	Why it belongs there
`event.eventId`	`Idempotency-Key` header	Prevents the same logical event from producing duplicate sends during retries.
`event.lead.email`	`to[0].email`	Supplies the intended recipient.
`event.lead.firstName`	`to[0].name`	Gives the recipient a display name where available.
`event.lead.firstName`	`subject`, `text`, `html`	Supports limited, controlled personalization.
Server-side constant	`from.email`	Ensures the sender uses a domain you have verified.
Server-side constant	`from.name`	Keeps sender identity consistent.
Server-side template	`subject`, `text`, `html`	Prevents untrusted upstream content from becoming arbitrary email content.

This separation is especially important if the source is a public form. A form user may legitimately control a name or message field, but they should not be able to choose the sender address, alter reply handling, add arbitrary headers, select recipients, or decide whether a message is classified as marketing.

Use plain text as well as HTML. HTML improves presentation, but the text version supports mail clients and recipients that do not render HTML. It also provides a simpler fallback for accessibility and troubleshooting.

Where the Volanea API key belongs

The Volanea API key belongs in a server-side secret store associated with the middleware runtime. In the Worker example, that is env.VOLANEA_API_KEY. In other environments, use the equivalent protected mechanism:

A cloud function secret or encrypted environment variable.
A deployment-platform secret store.
A managed secrets service.
An automation platform’s encrypted connection or private credential field, if the platform supports one.

Do not place the Volanea key in any client-visible location. That includes browser JavaScript, a static HTML page, a public Cyfe dashboard, a shared dashboard URL, a front-end environment variable bundled into a site, a mobile application, or a public webhook URL query string.

An API key is a sending credential. Anyone who obtains it may be able to send messages as your verified domain, consume account quota, damage sender reputation, or create an incident that requires key rotation. A dashboard is also the wrong place to store it because Cyfe does not expose a documented outbound HTTP action that would need the credential in the first place.

Store the source-system authentication secret separately from the Volanea key. In the example, INTEGRATION_SECRET authenticates the incoming source event and VOLANEA_API_KEY authenticates the outbound email request. Using separate credentials limits the impact of a compromise and makes rotation easier.

Use Zapier or Make only in the correct direction

Cyfe’s documented Zapier relationship centers on sending data into Cyfe through the Push API. It does not turn Cyfe dashboards into an outbound event source for Volanea. Therefore, a workflow that starts with Cyfe widget updated should not be assumed to exist.

You can still use Zapier or Make in the overall solution if the original application is supported as a trigger. The route should look like this:

Source app event
  -> Zapier or Make trigger
  -> Webhooks or HTTP request action
  -> your protected middleware endpoint
  -> Volanea send API
  -> optional Cyfe Push API update

For a simple automation, the middleware can be replaced by an HTTP action that calls Volanea directly only if the automation platform can securely store the Volanea credential, set the Authorization header, send JSON, and supply a stable idempotency key. Even then, middleware is often the stronger long-term choice because it gives you validation, rate limiting, structured logs, controlled templates, recipient checks, and a place to change providers or message logic without rebuilding every automation.

If you do call Volanea directly from middleware, retain a single authoritative send path. Avoid having one Zap send through Volanea while another background process sends the same message based on Cyfe reporting data. Duplicate architecture becomes duplicate email surprisingly quickly.

Configure deliverability before testing production events

Before enabling the flow, verify the sender domain you will use in the from.email field. The address must belong to a domain configured for sending in Volanea. Do not use a random mailbox, a teammate’s consumer inbox, or an address that has not been authorized for the account.

Then prepare a minimal production checklist:

Use a sender address on the verified domain, such as hello@your-verified-domain.com.
Confirm the visible sender name accurately identifies your organization.
Add a working reply path if recipients may respond.
Send test events to controlled inboxes at more than one mailbox provider.
Confirm that the email body renders correctly in both HTML and text form.
Verify that retries reuse the same idempotency key.
Check that a Cyfe metric failure does not replay the Volanea send.
Verify suppression and delivery behavior through your email logs and events.

When an event contains an address collected from a form or imported system, validate its format before attempting the send. For a quick preflight, use the email address verification tool, but treat verification as one layer of quality control rather than a substitute for consent, suppression handling, or event-specific business rules.

When this breaks: failures specific to the Cyfe hop

The main troubleshooting insight is simple: Cyfe is not the outbound sender in this architecture. Therefore, a failure must be assigned to the correct hop instead of being described vaguely as a Cyfe problem.

A Cyfe retry cannot duplicate an outbound Volanea send

Cyfe’s documented Push API accepts values from your application. It does not document a reverse webhook delivery system for dashboard events, so there is no Cyfe outbound retry behavior that should be sending the same Volanea request twice.

Duplicates are more likely to originate in the real trigger path: the source application retrying a webhook, Zapier or Make retrying an HTTP module, a queue replaying an event, a user submitting a form twice, or middleware retrying after a timeout. The defense is a stable Idempotency-Key built from the original business-event ID, not from a random UUID generated on every retry.

For example, lead-created:lead_01J... is safe to reuse for retries of the same lead-created event. A brand-new random value is not safe because Volanea sees it as a new send request.

A timeout can mean the email was accepted anyway

A network timeout between middleware and Volanea creates ambiguity. Your code may not receive the HTTP response, but the API may have accepted the request before the connection failed. Retrying without the same idempotency key risks sending a duplicate message.

Use the same idempotency key whenever you retry a logical event. Record the original event ID, request time, API result, and response status in your logs. That record lets you distinguish an upstream delivery retry from a new business event.

Cyfe dashboard values are not complete contact payloads

A Cyfe widget is intentionally optimized for metrics. It may show a total count, chart point, or KPI but not the recipient email, consent state, source-record ID, template choice, and other data required for a safe send.

Do not attempt to reconstruct recipient-level email events from a dashboard aggregate. If an upstream platform has different field availability on different plans, account tiers, connectors, or objects, handle that at the source integration layer. Your middleware should reject events missing required fields rather than guessing an address or sending generic mail to an unrelated contact.

A Push API update can fail after email acceptance

The optional Cyfe metric update happens after Volanea accepts the email request in the example. Cyfe may return an error, the Push API endpoint may be unavailable, or the dashboard metric update may time out. That should be visible in monitoring, but it must not automatically trigger another email send.

Treat email dispatch and dashboard analytics as two separate operations. If you need guaranteed analytics, put Cyfe updates on their own retry queue keyed to the event ID. Never retry the whole workflow from the beginning merely because the reporting step failed.

A scheduled Cyfe report is not a Volanea delivery status

Cyfe can schedule dashboard reports, but receiving a scheduled report only confirms that Cyfe generated and emailed a dashboard export. It does not prove that a Volanea transactional message was delivered, opened, or acted on.

For transactional-email operations, use Volanea’s message and event records as the delivery source of truth. Use Cyfe to visualize aggregates such as accepted sends, bounces, complaints, or delivery rates after you intentionally feed those metrics into it.

Operational patterns that scale better

As volume grows, move from direct synchronous handling to a small event-processing design. The key is to preserve the original event ID through every hop.

A robust event record may include:

sourceEventId: lead_01J...
eventType: lead.created
occurredAt: 2026-10-03T14:20:00Z
recipientEmail: ada@example.com
messageType: lead-confirmation
idempotencyKey: lead-created:lead_01J...
volaneaStatus: accepted
cyfeMetricStatus: queued

This gives support and engineering teams a way to answer practical questions: Did the source create the event? Did middleware receive it? Did the email API accept it? Was the address invalid? Did the dashboard count update? Was a retry a duplicate or a new action?

For high-value emails such as receipts, password resets, account verification, or service outages, use a persistent queue and an event log. For low-risk contact acknowledgements, a synchronous endpoint may be sufficient, but it should still have idempotency and observable error handling.

If the use case is recurring marketing communication rather than an event-triggered transactional message, do not convert metric changes into campaign triggers. Build an intentional audience and consent workflow, apply unsubscribe requirements, and use a campaign-oriented sending process. A dashboard count is not an audience definition.

Why this design is better than trying to automate a dashboard

Putting Cyfe at the center of email automation creates an inverted design. Dashboards summarize events after they happen; they should not normally become the system that decides what a customer receives.

Using the source event instead provides several advantages:

Correctness: Recipient and event data come from the authoritative system.
Security: Sending credentials remain in server-side infrastructure.
Reliability: Idempotency can be tied to a stable event ID.
Privacy: You do not expose contact-level data in a reporting configuration unnecessarily.
Observability: Email status and dashboard status can fail independently and be diagnosed independently.
Flexibility: You can continue using Cyfe for reporting while changing the underlying application, automation platform, or middleware implementation.

This also creates a cleaner responsibility boundary. Cyfe answers, What is happening across the business? Volanea answers, How do we send and observe email? Your source system answers, What happened to this customer or record?

Implementation checklist

Before enabling production traffic, confirm each item below.

Conclusion

To send email from Cyfe with Volanea, do not look for a Cyfe marketplace plugin or an outbound dashboard webhook: Cyfe’s documented Push API is for sending data into Cyfe, not for emitting transactional events from it.

Use the original application event as the trigger, send it through a protected server-side route or source-triggered automation, call Volanea’s POST /v1/send endpoint with a verified sender and a stable idempotency key, and then update Cyfe with an aggregate metric if reporting is useful. That architecture is more secure, easier to troubleshoot, and far less likely to produce duplicate customer email.

FAQ

Can Cyfe directly trigger a Volanea email when a widget changes?

No documented Cyfe outbound webhook or widget-change automation trigger is available for that flow. Cyfe’s documented Push API accepts data into dashboards; it does not publish dashboard changes to Volanea.

What is the Cyfe trigger for this integration?

There is no Cyfe-side transactional trigger. Use the original source event, such as a created lead, completed signup, paid invoice, or resolved ticket, and treat Cyfe as the dashboard that reports the resulting activity.

Can I put my Volanea API key in a Cyfe widget or public dashboard configuration?

No. The key must stay in a server-side secret store or protected automation credential field. A client-visible configuration can expose a credential capable of sending email from your domain.

How do I prevent duplicate messages when the source retries?

Build the Idempotency-Key from the original event ID and reuse it for every retry of that same event. Do not generate a new random key for each retry attempt.

Can Cyfe report on Volanea email activity?

Yes. Your middleware can push aggregate metrics such as accepted sends or bounce counts to a Cyfe Push API widget. Keep that reporting update separate from the email send so a dashboard failure cannot cause a duplicate email.

How to Send Email From Cyfe With Volanea: The Reliable Route