Build Make.com to SAP ERP Integration Pipeline [2026]

Building a resilient Make.com to SAP ERP integration pipeline requires connecting via secure SAP Service Layer OData or RFC/BAPI endpoints, enforcing strict idempotency keys to prevent duplicate records, and deploying Break error handlers for zero transaction loss during ERP maintenance windows. Mete Güneş deploys production SAP-cloud automation for manufacturing SMEs in 2 to 3 weeks. For mid-market manufacturing and wholesale enterprises operating SAP Business One or SAP S/4HANA, digital agility frequently grinds to a halt at the ERP boundary. While marketing, e-commerce, and CRM operations move at the speed of modern cloud SaaS platforms, SAP systems operate with rigorous transactional governance, strict database locking, and complex internal authorization rules. When companies attempt to bridge this divide using fragile spreadsheet uploads or manual human data re-entry, order fulfillment delays balloon, inventory counts drift out of alignment, and operational overhead escalates. In this engineering blueprint, we break down how to architect a secure, bidirectional Make.com to SAP ERP integration pipeline, compare modern OData Service Layer endpoints against legacy BAPI/RFC protocols, prevent catastrophic duplicate order creation with Datastore idempotency, and guarantee zero-downtime transaction recovery during ERP maintenance windows.

The architectural challenge of connecting cloud automation with SAP ERP

Enterprise Resource Planning (ERP) systems like SAP form the single source of truth for corporate finance, material requirements planning (MRP), inventory valuation, and regulatory compliance. Consequently, SAP is engineered with strict transactional isolation and defensive relational schemas: an invalid tax code, a missing business partner identifier, or an unmapped warehouse location triggers immediate transaction rollbacks to protect ledger integrity.

In contrast, cloud automation platforms like Make.com thrive on high-velocity JSON webhooks, asynchronous event streams, and rapid third-party API mutations. When an unbuffered cloud webhook attempts to inject hundreds of e-commerce orders directly into SAP without intermediate schema validation or concurrency governance, standard failure modes emerge: database lock timeouts, corrupted draft invoices, and orphaned line items.

According to the official SAP Business One Service Layer Reference Guide, integrating external cloud webhooks directly against core SQL tables via direct ODBC/JDBC connections is strictly unsupported and violates vendor warranties. Modifying SAP relational tables from outside the application layer bypasses essential business logic checks (such as credit limit verification, inventory batch allocation, and journal entry balancing). Therefore, resilient cloud-to-ERP architecture demands a decoupled, stateless middleware pipeline that interacts exclusively through official, supported application programming interfaces.

For mid-market manufacturing companies exploring cloud automation options, review our comparative guide on Boutique vs Enterprise AI Consulting and our core AI & Workflow Automation Solutions.

SAP connection methods compared: OData Service Layer, BAPI, and RFC connectors

When engineering a Make.com to SAP integration pipeline, systems architects must select the optimal connection interface based on ERP product version (SAP Business One vs SAP ECC / S/4HANA), hosting topology (on-premise vs private cloud), and network security requirements.

The following technical comparison matrix evaluates the three primary SAP integration protocols:

Technical Criterion	SAP Service Layer (OData v3/v4 REST)	BAPI via SAP .NET Connector (NCo / RFC)	SAP NetWeaver / Cloud Integration (CPI)
Target ERP System	SAP Business One (on HANA / MS SQL)	SAP ECC 6.0 & SAP S/4HANA On-Premise	SAP S/4HANA Cloud & Large Enterprise Suites
Protocol & Payload Format	Stateless HTTP/HTTPS, JSON & OData XML	Binary TCP / RFC Remote Function Calls	Enterprise SOAP, OData, and Managed Middleware
Firewall & Gateway Setup	Standard HTTPS (Port 50000) over SSL/TLS	Requires VPN tunnel or dedicated SAP Gateway	Native SAP Cloud Connector managed tunnel
Make.com Compatibility	100% Native via HTTP & Webhook modules	Requires intermediate custom Node.js bridge	Supported via custom REST webhook adapters
Concurrency & Scalability	High (Apache/Nginx multi-threaded worker pool)	Limited by available RFC connection work processes	Enterprise auto-scaling managed by SAP Cloud
Implementation Cost for SMEs	Low ($3,850 – $4,500 turnkey sprint)	High ($25,000+ custom middleware coding)	Very High ($50,000+ annual licensing fees)

For the vast majority of mid-market manufacturing and wholesale SMEs operating SAP Business One, the SAP Service Layer represents the gold standard. Built upon open OData and REST standards with native JSON payload serialization, the Service Layer exposes all standard business objects (Items, BusinessPartners, Orders, Invoices, DeliveryNotes) over encrypted HTTPS. Make.com communicates natively with Service Layer endpoints using standard HTTP modules, eliminating the need for expensive proprietary middleware licenses or brittle COM-based DI API bridges.

For guidance on troubleshooting cloud webhook pipelines and resolving payload errors, explore our technical tutorial on Fixing Broken Make.com Scenarios After API Changes.

Step-by-step pipeline blueprint: Webhook ingestion to SAP sales order creation

A production-grade Make.com to SAP ERP pipeline operates as a deterministic six-stage transaction pipeline. Each stage validates, enriches, and verifies state before proceeding to the next operational phase:

1. Stage 1: Webhook Ingestion & Cryptographic Verification: Inbound order payloads from external channels (Shopify, WooCommerce, custom B2B distributor portals) hit a custom Make.com webhook endpoint. The scenario immediately verifies the incoming HMAC-SHA256 request signature against the originating platform's secret key, immediately discarding unauthorized or tampered requests.
2. Stage 2: Datastore Idempotency Inspection: The incoming unique order identifier (e.g., ecommerce_order_10842) is checked against a persistent Make.com Datastore. If a record with this key already exists in Completed or Processing state, execution terminates safely, preventing duplicate sales orders from being created in SAP during upstream webhook retries.
3. Stage 3: Data Transformation and Currency Mapping: External customer details and SKU line items are mapped into SAP-compliant JSON structures. Product SKUs are translated into internal SAP ItemCode identifiers, international currencies are converted to the company's local book currency using live central banking exchange rates, and freight tax codes are assigned according to regional destination rules.
4. Stage 4: Session Authentication via Service Layer Login: The scenario executes a secure POST https://sap-server:50000/b1s/v1/Login request with company database credentials, capturing the session cookie (B1SESSION) and CSRF token required for transactional mutations.
5. Stage 5: Transactional Order Injection (POST /Orders): The enriched payload is transmitted to the SAP Service Layer Orders endpoint:

   POST /b1s/v1/Orders
   Headers:
     Content-Type: application/json
     Cookie: B1SESSION=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
   Payload:
   {
     "CardCode": "C20000",
     "DocDueDate": "2026-10-25",
     "NumAtCard": "PO-10842",
     "DocumentLines": [
       {
         "ItemCode": "ITEM-A04",
         "Quantity": 25.0,
         "UnitPrice": 142.50,
         "WarehouseCode": "01"
       }
     ]
   }Copy

6. Stage 6: Confirmation Dispatch and State Finalization: Upon receiving an HTTP 201 Created response from SAP containing the generated DocEntry and DocNum, the scenario updates the internal Datastore record to Completed, attaches the official SAP order number to the external e-commerce record, and dispatches an automated fulfillment notification to the operations team via WhatsApp or Slack.

By enforcing this structured sequence, the pipeline bridges disparate data models deterministically, guaranteeing that every external order record is verified, sanitized, and permanently reconciled in the central general ledger.

Preventing duplicate records: Datastore idempotency and transaction locks

In manufacturing and e-commerce distribution, duplicate order creation represents a severe operational failure. When an upstream webhook provider (such as Stripe or Shopify) experiences a network timeout during order processing, its automated retry policy re-dispatches the identical order payload seconds later. If the integration scenario lacks idempotency, two identical sales orders are created in SAP, triggering double inventory reservations, duplicate factory production orders, and incorrect billing statements.

To eliminate this failure mode, our architecture deploys a Two-Phase Idempotency Lock using Make.com Datastores:

• Phase 1 (Lock Acquisition): At the entry module, the scenario executes an atomic Add/Replace Record operation in the Datastore with key ORDER_{ID}, setting status to PENDING and recording the current UNIX timestamp. If the Datastore indicates that the key was already locked within the past 10 minutes, the duplicate incoming execution is routed to an Ignore directive and safely dropped.
• Phase 2 (Final Commit): Only after the SAP Service Layer returns an explicit HTTP 201 Created status code is the Datastore record updated to COMMITTED alongside the newly assigned SAP DocEntry. If downstream SAP processing fails due to a validation error, the lock is released or marked as FAILED to permit supervised administrative reprocessing.

This deterministic pattern guarantees that no matter how many times an upstream system retries a webhook during network instability, exactly one sales order is committed to the SAP database.

Zero-loss error recovery: Configuring Make.com Break modules for SAP maintenance

Enterprise ERP installations undergo routine maintenance: nightly database re-indexing, automated transaction log backups, HANA memory defragmentation, and weekend software patch cycles. During these maintenance intervals (which typically last 15 to 45 minutes), the SAP Service Layer port rejects inbound connections, returning HTTP 502 Bad Gateway or connection timeout errors.

According to resilience benchmarks published by the Make Community Architecture Knowledge Base and verified SAP Enterprise Integration Standards, in standard unhardened automation scenarios, connection rejections cause immediate execution termination, resulting in dropped customer transactions that must be manually reconstructed from server log files. In our production architecture, this risk is eliminated by configuring the Make.com Break Directive:

1. Attach Error Handler Route: An error route is connected directly to the SAP Service Layer HTTP module.
2. Configure Break Directive Settings: The Error Handler is set to Break, configured with 5 retry attempts at a 15-minute interval. This provides a total recovery window of 75 minutes—sufficient to span standard SAP maintenance cycles.
3. Enable Incomplete Executions: In scenario settings, Allow storing of Incomplete Executions is toggled ON. When SAP goes offline, Make.com halts the scenario, serializes the exact order bundle into encrypted incomplete execution storage, and waits for the next scheduled retry interval.
4. Automatic Resumption: As soon as SAP maintenance concludes and the Service Layer resumes answering HTTP requests, the Break module executes the pending order payload successfully and commits the transaction without human intervention.

Operations teams no longer need to coordinate automation scenario shutdowns prior to scheduled ERP maintenance. The integration layer behaves as an intelligent, self-healing buffer, absorbing transactions continuously and synchronizing them smoothly once ERP services are fully restored.

For broader automation cost analyses, use our interactive Automation ROI Calculator.

Security, data residency, and compliance: Protecting ERP data under KVKK and GDPR

SAP ERP databases house an enterprise's most sensitive operational assets: proprietary pricing tables, client bank accounts, manufacturing bill of materials (BOM), and employee payroll data. Exposing these systems to cloud automation requires stringent adherence to international data privacy and security mandates (including 6698 sayılı KVKK, European Union GDPR, and SOC2 compliance).

Our SAP-Make.com integration pipelines enforce a multi-layered security perimeter:

• Least-Privilege API Service User Provisioning: The Make.com scenario never authenticates using master administrative accounts (such as manager). A dedicated SAP Service User (e.g., B1_MAKE_API) is provisioned with strictly scoped authorizations: permission to insert Sales Orders and query Business Partners, with zero access to financial ledgers, payroll records, or administrative system setup tables.
• Encrypted Transport over TLS 1.3: All network traffic between Make.com cloud workers and the on-premise or cloud SAP Service Layer transits exclusively over TLS 1.3 encrypted tunnels. Direct public IP access is blocked using reverse proxy gateways (such as Cloudflare Tunnel or AWS API Gateway) with strict IP allowlisting matching Make.com's regional worker IP ranges.
• Payload Data Sanitization & Anonymization: In compliance with KVKK and GDPR data minimization requirements, payment card numbers, sensitive national identification codes, and special category personal data are tokenized or redacted before webhook payloads transit external logging surfaces.
• Immutable Transactional Audit Trail: Every automated transaction records the source webhook event ID, timestamp, user IP, and resulting SAP document number in an internal audit table, ensuring complete traceability for corporate accounting and external compliance audits.

By pairing military-grade security protocols with resilient, self-healing automation logic, mid-market manufacturers achieve seamless cloud agility while preserving absolute governance over their central ERP assets.

If your manufacturing or distribution enterprise is planning a Make.com to SAP ERP integration pipeline, contact Mete Güneş for a production implementation sprint or review our full engineering deliverables in the Pricing Directory.