# How to add WhatsApp to SAP S/4HANA > Source: https://netray.co/integrations/sap-s4hana-whatsapp > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer Connect the WhatsApp Business Platform to S/4HANA through a small middleware service that reads and writes via released OData APIs and listens to business events or output management triggers. Outbound messages use pre-approved templates, inbound replies are mapped to a specific document and posted back through the same APIs. Keep the middleware outside the SAP core so upgrades stay clean. ## System SAP S/4HANA ## Capability whatsapp ## Intro Most S/4HANA shops already notify people by email or Fiori inbox tasks, but the people who actually move material, suppliers, drivers, plant supervisors, live in WhatsApp. A supplier who ignores an automated PO email will often answer a WhatsApp message within minutes, and a supervisor approving a deviation from a loading dock is not opening a Fiori launchpad. The temptation is to bolt WhatsApp directly onto ABAP with a custom report that calls an HTTP endpoint. That works in a demo and then breaks at the first upgrade, the first template rejection, or the first auditor question about who approved what. The cleaner pattern is an external integration service that treats S/4HANA as a system of record behind released APIs. This page walks the S/4HANA side: which interfaces to use, how to trigger messages, how to map a reply to a document, and what to watch for with Meta's template and opt-in rules. It assumes either on-premise S/4HANA or a private edition, and notes where public cloud edition differs. ## Use Cases ### Supplier PO confirmation **Description:** After a purchase order is released, send the supplier contact a template message with PO number, items and requested dates, with quick-reply buttons for Confirm or Propose new date. A confirmation updates the schedule line; a new date opens a review task for the buyer. ### Delivery and goods issue notices to customers **Description:** When the outbound delivery is post-goods-issued, notify the customer contact with tracking details and the delivery document reference. Useful for distributors whose customers ask 'where is my order' by message anyway. ### Approval nudges for release strategies **Description:** A PO or purchase requisition waiting on a release code gets a short summary to the approver, with Approve and Reject replies. The service performs the release only after verifying the approver identity and calling the released API, not by trusting the phone number alone. ### Shop floor shortage alerts **Description:** A material shortage found at order release or at goods issue notifies the planner and the warehouse lead in a group-style routing, with the order, component and short quantity. Replies like 'in transit, 2 hours' are logged as a note on the order. ### Driver and carrier coordination **Description:** Inbound dock appointments and shipment pickups are confirmed with carriers by message, and their replies update custom status fields or a shipment-related tracking object rather than free-text email. ### Customer order status self-service **Description:** A customer sends an order number; the service looks up sales order status through the sales order API and replies with the open items and confirmed delivery dates, only after matching the sender to a known business partner contact. ## System Surface Released OData services on the SAP API Business Hub catalog, for example the purchase order, sales order, outbound delivery and business partner APIs (service names vary by release, check /IWFND/MAINT_SERVICE on your Gateway and the API Business Hub for your version). Business events and Enterprise Event Enablement (via SAP Event Mesh or the on-premise event channel in newer releases) to react to document creation or status change without polling. Output management (BRF+ based output control, or classic NAST condition records on older setups) to trigger a message when a document is output, which keeps the trigger inside the business-configured document flow. SAP Integration Suite or an on-premise middleware (SAP PO, a generic iPaaS, or a small custom service) as the broker between S/4HANA and the WhatsApp Cloud API or a BSP. Business partner contact data (mobile numbers and communication preferences in the BP master) as the source for recipient numbers; do not store numbers in free-text notes. IDocs (WE02 for monitoring, WE19 for testing) remain an option for partner-style asynchronous exchange when the middleware already speaks EDI. ## How It Works ### Pick the trigger and the document **Detail:** Decide whether the message fires from a business event, an output determination step or a scheduled poll of a CDS-based read API. Output determination is usually the most governable because business users already own it. ### Stand up the WhatsApp channel **Detail:** Register a WhatsApp Business Account through Meta (Cloud API) or a business solution provider. Verify the business, add a phone number, and draft message templates for each notification type. Templates need approval before use outside the 24 hour customer service window. ### Build the middleware service **Detail:** A small service receives the SAP trigger, enriches it by reading the document through the OData API, picks the template and recipient, and calls the WhatsApp messages endpoint. It stores a message log keyed by SAP document and WhatsApp message ID. ### Handle inbound webhooks **Detail:** Meta posts replies and delivery receipts to a webhook you expose. Validate the signature, match the sender to a business partner contact, resolve which document the reply refers to using the stored conversation context, and apply the intent (confirm, reject, ask question). ### Write back through released APIs **Detail:** Updates go through the same OData services under a technical user with minimal authorisations. For approvals, use the standard release APIs rather than direct table writes, so change documents and release logs remain correct. ### Add monitoring and a human fallback **Detail:** Surface failures (template rejected, number not on WhatsApp, API error) in a queue the buyer or planner can see. Falling back to email for undelivered messages keeps the process from stalling silently. ## Example Flows ### Supplier confirms a purchase order **Trigger:** A purchase order is output to a supplier whose contact has WhatsApp opt-in recorded. **Steps:** - Output determination calls the middleware with the PO number. - The service reads the PO header, items and schedule lines via the purchase order OData API. - It sends the po_confirmation template with Confirm and Propose date buttons. - The supplier taps Confirm; the webhook arrives and is matched to the PO. - The service posts the confirmation to the schedule line or order acknowledgement object used by the plant. **Result:** The buyer sees a confirmed PO without opening an email, and the supplier response time is measured in minutes. ### Goods issue triggers a customer notice **Trigger:** An outbound delivery is post-goods-issued for a customer with a notification preference set. **Steps:** - A business event for the delivery status change reaches the middleware. - The service reads delivery items and the carrier reference. - It sends the shipment template with the document number and expected arrival. - If the customer replies with a question, the message is routed to the customer service queue with the delivery attached. **Result:** Fewer 'where is my shipment' calls, and any reply that needs a human lands with context already attached. ## On Prem WhatsApp itself is a cloud service, so a fully air-gapped S/4HANA cannot use it directly. The practical on-prem pattern is a DMZ relay: the S/4HANA system only talks to an internal middleware, and only that middleware's outbound HTTPS to Meta (or to a BSP) crosses the perimeter. Message content should be limited to what is acceptable to leave the network: document numbers and status rather than pricing or drawings. Where even that is not acceptable, Signal-style or internal chat alternatives such as Teams or a self-hosted messenger are a better fit. If you add an AI model to interpret free-text replies, run it as an open-weight model on your own GPUs so supplier text and order data are not sent to a third-party API. ## Security - Use a technical communication user with a narrow role set, not a dialog user, and restrict the released services in the Gateway to what the flow needs. - Verify the Meta webhook signature on every inbound request and bind each conversation to a specific document and partner so a forwarded message cannot approve something else. - Keep phone numbers in the business partner master, restrict who can edit them, and record opt-in evidence (date, source) per contact. - Do not put prices, margins, export-controlled data or drawings in message bodies; send a reference and a link behind authentication instead. - Log every inbound action against the SAP document so auditors can see who confirmed or approved what and when. ## Options ### Use an SAP-ecosystem messaging product **Fit:** If you already run SAP Customer Engagement or another SAP-adjacent messaging suite, WhatsApp channels may be available as a configuration. Availability and S/4HANA data scope vary by product and edition, so confirm with your SAP account team. **Effort:** Low to medium, mostly configuration and template design, plus licence cost. ### Build in-house on Integration Suite or a small service **Fit:** Good when you have ABAP and integration developers and a handful of well-defined flows such as PO confirmation and delivery notices. **Effort:** Typically several weeks for one flow end to end, including template approval and testing. ### Work with a partner such as Netray **Fit:** Useful when you want two-way flows, free-text understanding or approvals, and want the AI part run privately. Netray can build the middleware with read-only defaults and human approval before any write. **Effort:** A scoped pilot is usually a few weeks; production hardening depends on number of flows and suppliers. ## Pitfalls - Free-form messages are only allowed inside the 24 hour window after a user message; everything else needs an approved template, and rejected templates stall launches. - Mobile numbers in the BP master are often missing, stale or stored without country codes. Cleanse them before go live. - Replying 'OK' is ambiguous when a supplier has several open POs. Always include the PO number in the template and the expected reply format. - Polling OData services for changes every minute will hurt a busy system; prefer events or output triggers. - Customising the standard document flow in ABAP to call WhatsApp directly creates upgrade friction; keep the logic outside the core. ## Faq ### Does S/4HANA have a native WhatsApp integration? **Answer:** There is no WhatsApp switch in core S/4HANA. Messaging channels exist in some SAP customer engagement products, but for ERP documents like purchase orders and deliveries you generally integrate through APIs and middleware. Check your edition and licence for current options. ### Can we send order data to customers over WhatsApp legally? **Answer:** It depends on your jurisdiction and contracts. You need documented opt-in, should avoid sensitive data in the message body, and should follow Meta's business policy. Your legal team should confirm, especially for regulated or export-controlled products. ### Can replies update SAP automatically? **Answer:** Yes for structured actions like button replies, through released APIs under a technical user. For free text, parse it into a proposed change and have a person approve it before posting, at least until accuracy is proven on your data. ### Does this work with S/4HANA Cloud public edition? **Answer:** Yes, with differences. Public edition restricts custom ABAP, so use released APIs, side-by-side extensions on SAP BTP and event channels. The middleware pattern stays the same, but the set of available triggers is narrower. ### How do we avoid duplicate messages? **Answer:** Store a message log keyed by document number, event type and recipient, and make the send idempotent. Output determination can re-trigger on reprint, and event delivery can repeat, so the middleware should check the log before sending. ## Search terms sap s4hana whatsapp integration, whatsapp for sap s/4hana, sap whatsapp api, send whatsapp from sap, sap purchase order whatsapp, sap whatsapp notifications, s4hana whatsapp business platform, sap whatsapp supplier confirmation, integrate whatsapp with sap, sap delivery notification whatsapp --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json