How to Send Email from SAP S/4HANA with Volanea

Sending email from SAP S/4HANA is best handled as an event-driven integration rather than by embedding a third-party email call in an ERP screen. This guide shows how to send email from SAP S/4HANA through SAP Event Mesh and SAP Integration Suite, with Volanea delivering the final transactional message over its REST API.

SAP S/4HANA does not provide a universal, vendor-agnostic outbound webhook switch that can post every business event directly to an arbitrary email API. Its cloud event model is designed around business events and SAP Event Mesh. The practical supported route is therefore: S/4HANA emits a business event, Event Mesh transports it, an Integration Suite integration flow transforms it, and the flow makes an authenticated HTTPS request to Volanea.

The recommended SAP S/4HANA email architecture

The integration has four distinct responsibilities. Keeping them separate makes the design easier to secure, operate, and change when either the ERP event or email content evolves.

1. SAP S/4HANA creates the business record and raises a business event.
2. SAP Event Mesh receives and distributes the event to an authorized consumer.
3. SAP Integration Suite, Cloud Integration subscribes to the event, enriches or transforms it, and calls Volanea.
4. Volanea accepts the email request and handles message delivery, delivery events, and provider-side sending infrastructure.

For a concrete example, this article uses the SAP S/4HANA Cloud business event BusinessPartner.Created. The trigger is not a generic “record created” webhook. It is the creation of a Business Partner in S/4HANA followed by publication of the corresponding business event. An integration can use the same pattern for another released event, such as a billing-document, sales-order, purchase-order, or supplier lifecycle event, provided that event is available in the tenant’s Event Catalog.

The pattern is intentionally asynchronous. A user creating a Business Partner should not have to wait for an email provider to respond. More importantly, a temporary email API failure should not roll back a valid ERP business transaction. Event transport and message delivery need separate failure handling.

What actually triggers the send in SAP S/4HANA

In this implementation, the trigger is the SAP S/4HANA BusinessPartner.Created business event. SAP publishes business events after relevant changes occur in the application. You activate the released event in the S/4HANA event configuration for the relevant communication arrangement and connect it to your Event Mesh instance.

The event tells downstream systems that a Business Partner was created; it is not usually a full customer-email document. That distinction matters. Business events are intentionally compact so that SAP can maintain them as stable integration contracts. The event gives the integration an identifier, while the integration flow decides whether it has enough data to send an email immediately or must retrieve approved additional data.

A representative CloudEvents envelope

When an S/4HANA business event is delivered through Event Mesh, consumers receive a CloudEvents-style envelope. The exact set of extension attributes and the data object can vary by event version and S/4HANA edition, so always confirm the released schema in your tenant’s Event Catalog before deploying. A representative Business Partner creation event looks like this:

{
  "specversion": "1.0",
  "type": "sap.s4.beh.businesspartner.v1.BusinessPartner.Created.v1",
  "source": "/default/sap.s4.beh",
  "id": "2a0b0e42-4c73-4f9c-b147-10dc8c8b8ef1",
  "time": "2026-09-23T10:15:42Z",
  "datacontenttype": "application/json",
  "data": {
    "BusinessPartner": "1000001"
  }
}

The concrete trigger fields used in this guide are:

This base event does not contain a recipient email address. That is normal. Do not guess that BusinessPartner is an email address, and do not assume every business partner is eligible for an email. In production, either send the notification to a configured internal operations mailbox or add an approved enrichment step that retrieves the intended recipient from a released S/4HANA API and checks communication preferences and consent.

Why middleware is the appropriate route

S/4HANA business events are designed to be consumed through SAP’s eventing and integration services, not as unrestricted direct webhooks to arbitrary SaaS URLs. SAP Event Mesh provides the event transport; SAP Integration Suite provides adapters, mappings, monitoring, secure material, retries, and controlled outbound HTTP connectivity.

This is preferable to putting email logic in an ABAP enhancement for several reasons. It prevents outbound email availability from becoming part of the interactive ERP transaction path. It avoids spreading API credentials through custom code and transports. It also gives integration administrators a dedicated place to inspect failed messages, replay an event safely, and update a template without changing S/4HANA business logic.

The middleware layer is not merely a technical workaround. It is the policy boundary where you can decide which ERP event should generate an email, which recipients are allowed, what data may leave SAP, and whether a message should be suppressed during testing or master-data migration.

Prerequisites before you build the flow

You need access to SAP services as well as a verified Volanea sending domain. The exact entitlement names differ by SAP contract and deployment, but the implementation requires the following capabilities.

• A SAP S/4HANA tenant where the required business event is released and can be activated.
• A configured SAP Event Mesh service instance and queue or subscription for the selected event topic.
• SAP Integration Suite with Cloud Integration enabled, plus permission to create and deploy an integration flow.
• Network egress from Integration Suite to Volanea’s HTTPS API endpoint.
• A Volanea API key with permission to send email.
• A Volanea sender identity or domain that has been configured and authenticated for the from address you intend to use.
• A deliberate recipient policy: a fixed internal mailbox for operational notifications, or an approved S/4HANA lookup and consent-validation design for external mail.

Set up the domain authentication before using the flow for customer-facing messages. A successful API response means Volanea accepted the request; it does not replace domain authentication, alignment, bounce processing, or suppression handling. The Volanea API setup and sending reference should be your source of truth for the current API endpoint, supported fields, and response format.

Decide what the email means

A creation event is a useful signal, but it does not automatically justify sending an external email. For example, creating a Business Partner can be part of a data migration, duplicate-resolution process, or internal master-data workflow. An email such as “Welcome” may be inappropriate until an account is activated, a contract is signed, or consent has been recorded.

A safer first deployment sends an internal operational notification such as “New Business Partner created: 1000001.” After the event pipeline is stable, add a controlled enrichment and eligibility stage for customer communications. This staged approach limits the risk of bulk accidental sends during historical loads or interface testing.

Configure the S/4HANA event source

Start in the S/4HANA extensibility and eventing configuration available to your edition. Find the released event in the Event Catalog, then create or update the communication configuration that sends selected events to SAP Event Mesh. SAP makes available event names, versions, topics, and payload schemas in the catalog; do not copy an event name from another tenant or release without confirming it is released for yours.

For this example, activate the Business Partner creation event and verify that Event Mesh receives it. Create a Business Partner in a non-production test client or tenant, then inspect the Event Mesh queue or subscription consumer. Save one real, redacted message as a test fixture. This is more reliable than building mappings against a manually invented event body.

A sound production subscription is narrow. Subscribe to the exact event topic or event type you need instead of a broad wildcard that captures every Business Partner change. A broad subscription can cause unexpected sends when address data, tax data, roles, or relationships change later.

Treat event versions as contracts

The .v1 in an event type is meaningful. Event schemas can evolve by version, and a new version may add, rename, or remove fields. Keep the expected type in an Integration Suite property or validation step. If a message arrives with an unexpected type, route it to an exception process rather than producing an email from a payload you have not reviewed.

For production operations, record at least the CloudEvents id, type, time, and the S/4HANA object identifier in integration logs. These fields make it possible to answer a support question such as: “Was an email triggered by Business Partner 1000001, and which ERP event caused it?”

Build the Integration Suite integration flow

Create an integration flow in SAP Integration Suite, Cloud Integration. The flow needs an AMQP sender connected to your Event Mesh queue, a script or mapping step, an HTTPS receiver that posts to Volanea, and an exception subprocess or error-handling branch.

A practical sequence is:

1. AMQP Sender: Consume the S/4HANA event from the Event Mesh queue.
2. Content Modifier or Groovy Script: Parse the CloudEvents payload, validate the event type, derive subject and HTML, and set the HTTP request headers.
3. Optional Request-Reply enrichment: Call a released S/4HANA API only if a recipient or approved display value is necessary and permitted.
4. Idempotency check: Check whether the event ID has already resulted in a send.
5. HTTPS Receiver: Make the POST request to the Volanea send-email endpoint.
6. Success persistence and monitoring: Store the event ID and Volanea response identifier, then acknowledge successful processing.
7. Exception subprocess: Preserve failure details, raise an alert, and allow controlled retry behavior.

Externalize values that differ by environment: Volanea API URL, sender address, internal notification recipient, and an environment label. Do not externalize the API key as a normal parameter. Externalized parameters can be convenient, but they are not the right place for a long-lived credential.

Recipient enrichment for external messages

If the business requirement is to email a Business Partner, add a Request-Reply call to a released S/4HANA API after the event arrives. Retrieve only the fields required for the message, such as a business partner’s approved email address and a communication-preference indicator. Do not export every available master-data field just because the integration can do so.

The enrichment step should explicitly handle these outcomes: no email address, multiple email addresses, an invalid email address, no consent, an inactive relationship, and an API authorization failure. Each outcome should have a defined policy. For example, “no email” can become an internal task; “multiple email addresses” can require a primary-address rule rather than a first-record-wins implementation.

Transform the SAP event into a Volanea REST request

The following Groovy script is intended for a SAP Integration Suite Cloud Integration script step immediately before an HTTP receiver adapter. It parses the event, validates the event type, builds a simple internal-notification message, and retrieves the Volanea API key from SAP secure storage.

The HTTP receiver adapter is configured to use POST, content type application/json, and the Volanea email-send URL from the current Volanea API documentation. The script creates the body and headers; the receiver adapter performs the actual HTTPS call. Using a configured recipient for this first flow is intentional: the source BusinessPartner.Created event only identifies the business object and does not itself provide a safe external recipient address.

import com.sap.gateway.ip.core.customdev.util.Message
import com.sap.it.api.ITApiFactory
import com.sap.it.api.securestore.SecureStoreService
import groovy.json.JsonOutput
import groovy.json.JsonSlurper

Message processData(Message message) {
    def event = new JsonSlurper().parseText(message.getBody(String))

    // Validate the concrete SAP S/4HANA business-event contract.
    if (event.type != 'sap.s4.beh.businesspartner.v1.BusinessPartner.Created.v1') {
        throw new IllegalArgumentException("Unexpected event type: ${event.type}")
    }

    String eventId = event.id?.toString()
    String occurredAt = event.time?.toString()
    String businessPartner = event.data?.BusinessPartner?.toString()

    if (!eventId || !businessPartner) {
        throw new IllegalArgumentException('Missing CloudEvents id or data.BusinessPartner')
    }

    // These are externalized iFlow parameters, not SAP event fields.
    String fromAddress = message.getProperty('VolaneaFromAddress')
    String operationsRecipient = message.getProperty('OperationsRecipient')

    if (!fromAddress || !operationsRecipient) {
        throw new IllegalArgumentException('Missing VolaneaFromAddress or OperationsRecipient')
    }

    // Read the key from SAP Integration Suite Security Material.
    SecureStoreService secureStore = ITApiFactory.getService(SecureStoreService.class, null)
    def credential = secureStore.getUserCredential('volanea-api-key')
    if (credential == null) {
        throw new IllegalStateException('Secure material volanea-api-key was not found')
    }
    String apiKey = credential.getPassword().toString()

    // Field mapping: SAP CloudEvents -> Volanea email payload.
    def volaneaPayload = [
        from   : fromAddress,
        to     : [operationsRecipient],
        subject: "Business Partner ${businessPartner} created in SAP S/4HANA",
        html   : """<p>A SAP S/4HANA Business Partner was created.</p>
<p><strong>Business Partner:</strong> ${businessPartner}</p>
<p><strong>Event type:</strong> ${event.type}</p>
<p><strong>Occurred at:</strong> ${occurredAt ?: 'not supplied'}</p>
<p><strong>SAP event ID:</strong> ${eventId}</p>"""
    ]

    message.setHeader('Authorization', "Bearer ${apiKey}")
    message.setHeader('Content-Type', 'application/json')
    message.setHeader('Accept', 'application/json')
    message.setHeader('X-SAP-Event-ID', eventId)
    message.setBody(JsonOutput.toJson(volaneaPayload))
    return message
}

The resulting HTTP request body is conceptually:

{
  "from": "erp-notifications@example.com",
  "to": ["master-data-operations@example.com"],
  "subject": "Business Partner 1000001 created in SAP S/4HANA",
  "html": "<p>A SAP S/4HANA Business Partner was created.</p>..."
}

The mapping is deliberately visible in code: data.BusinessPartner becomes the human-readable identifier in the subject and HTML body; id becomes the correlation header; and time is included as context. If your Volanea account uses a different documented recipient representation, template field, or idempotency field, change the body to match the current documented API contract rather than relying on an assumed payload shape.

Keep the Volanea API key out of client-visible configuration

Create a Security Material entry in SAP Integration Suite for the Volanea API key. A common approach is to store it as a User Credentials artifact named volanea-api-key, placing a non-sensitive placeholder in the username field and the actual API key in the password field. The Groovy script retrieves the credential at runtime through the secure-store service and adds it to the outbound Authorization header.

The key must not sit in an SAPUI5 application, browser-side JavaScript, a public Git repository, a plain-text iFlow parameter, an email template, or a custom field on an S/4HANA record. Anything delivered to a browser can be copied by a user. Anything stored alongside ordinary configuration tends to be exposed in exports, screenshots, transports, support tickets, or overly broad administrator roles.

Use separate Volanea API keys for development, test, and production. This allows test systems to send only to controlled mailboxes and lets you revoke one environment without breaking the others. If Volanea supports restricted keys, grant only the sending scope required by this integration. Rotate the key through the secure-material artifact, redeploy or refresh the flow as required by your landscape, and confirm both the new and retired key behavior in a controlled window.

Test the integration before enabling real recipients

Start with a test Event Mesh queue and an internal mailbox. Create a test Business Partner, then trace the message across all four layers: S/4HANA event publication, Event Mesh delivery, Integration Suite processing, and Volanea acceptance.

A useful acceptance checklist includes:

• The event type is exactly the one the flow expects.
• id and data.BusinessPartner are present in the received message.
• The Integration Suite log has the same event ID as the message header sent to Volanea.
• The outbound sender address belongs to an authenticated domain.
• The message reaches only the configured test recipient.
• A duplicate delivery of the same event does not create a duplicate email.
• A deliberately invalid API key produces an observable, actionable failure without exposing the secret in logs.

Do not log raw API credentials or a full recipient list in unrestricted logs. Log a correlation identifier, a masked recipient, the SAP event ID, HTTP status, and the Volanea response ID when available. This is enough for support without turning integration monitoring into a secondary database of personal data.

When this breaks: failures specific to this integration hop

An event-driven email path has several failure modes, and the correct response depends on where the failure occurred. Treating every exception as “retry immediately” can create duplicate emails or conceal a data-quality issue.

Retries can create duplicate sends

Event Mesh and Integration Suite provide at-least-once delivery patterns. A message can be delivered again after a transient network issue, timeout, worker restart, or failure to acknowledge processing. The most dangerous case is when Volanea accepted the send but the HTTP response did not reach Integration Suite. Retrying then may send the same email twice.

Use the CloudEvents id as the idempotency key for the entire flow. Before calling Volanea, check a durable idempotency store keyed by event ID and event type. Only mark the key as completed after a confirmed response. If Volanea offers a documented idempotency header or request field, pass the same SAP event ID there as well. An email provider-side idempotency control plus an integration-side store is stronger than either control alone.

HTTP timeouts are ambiguous

A connect timeout generally means no request was made. A read timeout after a successful connection is ambiguous: Volanea may have received and accepted the request even though SAP did not receive a response. Do not automatically classify all timeouts as safe retries.

Set a reasonable receiver timeout, but make the business process resilient to uncertainty. Persist the SAP event ID before the call, capture the request correlation ID, and use your idempotency design to avoid a second send. If the provider exposes delivery or request lookup capabilities, use the correlation ID for reconciliation before manually replaying a failed message.

Event payload fields may be missing or differ by release

Do not assume that every S/4HANA edition, scope item, event version, or plan exposes the same event payload. A field visible in a sample payload may not be released in your tenant. Some events supply only an object key; others contain more context. This is why the script validates required fields and why the first implementation uses a configured internal recipient instead of inventing a customer email address.

When a required field is absent, send the message to an exception route with the event ID and schema version, not to Volanea. Fix the mapping against the Event Catalog schema or add a released API enrichment step. Avoid parsing display text, relying on undocumented fields, or using a “first email address” fallback.

Authentication and sender failures need different owners

A 401 or 403 response usually indicates an invalid, expired, revoked, or insufficiently scoped API key. A sender-identity rejection usually indicates that the from address or domain is not configured as expected. A 400 response often indicates a malformed payload or invalid recipient. A 429 or 5xx response may be transient, but should still be retried with bounded backoff and idempotency protection.

Route these errors differently. Credential and sender-identity errors go to the integration and email-platform owners. Missing recipient data or consent failures go to the business-data owner. Repeated provider availability failures go to operations with a queue depth and retry-age alert.

Design for deliverability and data governance

The integration can be technically successful while the message performs poorly in recipients’ inboxes. Use a purpose-specific sender such as erp-notifications@example.com, authenticate the sending domain, and make the display name clear. A customer should understand why the message exists and which business process caused it.

Keep the payload data-minimal. Sending a Business Partner identifier and a lifecycle status may be appropriate for an internal mailbox. Sending bank details, tax identifiers, account balances, or unrestricted contact data in an email is generally not. Email is often forwarded, retained, and indexed outside the original ERP access model.

For external communication, implement consent and preference logic before the Volanea call. Transactional notices may have a different legal basis from marketing messages, but that does not remove the need to honor suppressions, invalid-address outcomes, and local policy. Make the email category explicit in your design so a later change does not accidentally turn an operational event feed into a campaign engine.

Alternatives and when to use them

SAP Integration Suite is the strongest choice when S/4HANA is a core system, the event volume matters, and you need managed monitoring, secure credentials, and governed connectivity. It also suits organizations already using Event Mesh for other enterprise events.

For a small proof of concept, an external automation service can subscribe only if it has a supported way to consume the SAP event transport or receive an intermediate webhook from your SAP integration landscape. Do not treat a consumer automation tool as a substitute for secure event handling when the payload includes ERP identifiers or customer data. It may be useful for non-sensitive internal alerts, but evaluate its credential handling, retry semantics, data residency, and auditability first.

An ABAP-based outbound HTTP implementation can be appropriate for an on-premises or private-cloud S/4HANA deployment where your development standards permit it. It is not a drop-in replacement for the cloud event pattern, and it puts more responsibility on your SAP development team for secret storage, connectivity, retries, monitoring, and duplicate prevention. For cloud-oriented integrations, Event Mesh plus Integration Suite keeps the extension outside the core.

Operating the integration after launch

Monitor more than HTTP success rates. Track event intake, transformed messages, suppressed messages, idempotency hits, HTTP failure classes, retry age, and Volanea acceptance or delivery events. A sudden rise in Business Partner creation events may be a valid migration, a source-system loop, or an accidental configuration change; all three can produce a high email volume.

Maintain a runbook that identifies the queue, iFlow, secure-material artifact owner, sender domain, recipient policy, idempotency store, and escalation contact. Include a safe replay procedure. The procedure should explain how to replay an event only after checking the event ID, whether Volanea already accepted it, and whether the recipient remains eligible.

Finally, keep ERP and email retention policies aligned. Integration logs should retain enough metadata for troubleshooting but not indefinitely retain full personal-data payloads. Set access controls so that people who can inspect message traces are authorized to see the business information those traces contain.

Conclusion

To send email from SAP S/4HANA reliably, use the system’s released business-event model rather than trying to bolt a generic direct webhook onto the ERP transaction. A BusinessPartner.Created event can move through SAP Event Mesh to SAP Integration Suite, where a controlled flow validates the payload, retrieves a protected Volanea API key, transforms the event into an email request, and records enough correlation data for operations.

The important production details are not the POST request alone. They are validating the released event schema, separating object identifiers from recipient data, protecting credentials in SAP secure storage, preventing duplicate sends during retries, and monitoring the boundary between Event Mesh, Integration Suite, and the email API. With those controls in place, the same pattern can support many other S/4HANA lifecycle notifications without putting email infrastructure inside the ERP core.

FAQ

Can SAP S/4HANA send directly to the Volanea API?

S/4HANA business events are normally integrated through SAP Event Mesh rather than a universal direct-to-vendor webhook feature. SAP Integration Suite is the recommended outbound HTTP layer because it provides secure credential storage, mappings, monitoring, and retry control.

What SAP S/4HANA action starts the email in this example?

The send starts when SAP S/4HANA creates a Business Partner and publishes the released BusinessPartner.Created business event. The Integration Suite flow consumes that event from SAP Event Mesh and sends the email only after its validation and idempotency steps pass.

Where should the Volanea API key be stored?

Store it in SAP Integration Suite Security Material, such as a User Credentials artifact, and retrieve it at runtime from the secure store. Never place it in browser-visible SAPUI5 configuration, normal iFlow parameters, source code, or business-record fields.

How do I stop duplicate emails after a retry?

Use the CloudEvents id as a durable idempotency key. Check it before sending, record a confirmed send after a successful response, and use the same ID in any Volanea-supported idempotency mechanism. Treat post-request timeouts as ambiguous rather than automatically safe to retry.

Can the flow email the newly created Business Partner?

Not safely from the creation-event payload alone, because the event may provide only the Business Partner identifier. Add a released S/4HANA API enrichment step to retrieve an approved email address, then apply consent, preference, and validation rules before sending.