Custom SAP API integration means connecting non-SAP applications (your CRM, your e-commerce platform, your warehouse system, your data warehouse) to your SAP ECC or S/4HANA system using SAP's native integration interfaces — BAPIs for synchronous business transactions, RFCs for low-level function calls, OData services for REST-style access, and IDocs for asynchronous document exchange. FreedomDev has been building these integrations for mid-market companies since SAP NetWeaver was new. We do this without forcing you to deploy SAP Process Integration (PI/PO) or SAP Integration Suite — middleware layers that cost more than the rest of your integration project and require dedicated SAP basis expertise to maintain. Lightweight, direct, and your engineers can read the code.
Anyone proposing SAP custom API integration without naming protocols is selling a wrapper. The work happens at the protocol layer, and choosing the wrong protocol turns a 2-week integration into a 4-month project.
**BAPI (Business Application Programming Interface).**
BAPIs are SAP's stable, business-level synchronous APIs for executing transactions in SAP. Examples: `BAPI_SALESORDER_CREATEFROMDAT2` to create a sales order, `BAPI_GOODSMVT_CREATE` to post a goods movement, `BAPI_PO_CREATE1` to create a purchase order. They sit on top of underlying transactional logic and are the canonical "create a sales order in SAP from an external system" interface.
When to use BAPIs: - The business operation you need maps to a published BAPI (most master-data and transactional flows do) - You need synchronous confirmation — the calling system needs to know immediately whether the SAP transaction succeeded - You are connecting from a system that supports SOAP or RFC client libraries
Our engineers have built this exact solution for other businesses. Let's discuss your requirements.
Custom SAP API integration means connecting non-SAP applications (your CRM, your e-commerce platform, your warehouse system, your data warehouse) to your SAP ECC or S/4HANA system using SAP's native integration interfaces — BAPIs for synchronous business transactions, RFCs for low-level function calls, OData services for REST-style access, and IDocs for asynchronous document exchange. FreedomDev has been building these integrations for mid-market companies since SAP NetWeaver was new. We do this without forcing you to deploy SAP Process Integration (PI/PO) or SAP Integration Suite — middleware layers that cost more than the rest of your integration project and require dedicated SAP basis expertise to maintain. Lightweight, direct, and your engineers can read the code.
SAP's official answer to "how should I integrate with SAP" is to buy SAP Process Integration (PI), now rebranded as Process Orchestration (PO), or the newer cloud-based SAP Integration Suite (BTP). These are full-featured ESB-style middleware platforms. The economic reality for mid-market companies: - **SAP PI/PO licensing** runs $80k-$300k+ depending on edition, plus per-message fees on some agreements - **Implementation** requires SAP basis consultants charging $200-$400/hour and typical 6-12 month rollouts - **Maintenance** demands dedicated SAP PI expertise — a skill set that is rare and expensive and frequently lacking on internal IT teams - **Operational overhead** of running another SAP system (patching, monitoring, basis administration) adds annual cost For a mid-market company that needs to connect, say, Salesforce CRM + an e-commerce front-end + a warehouse system to SAP, deploying PI/PO is wildly disproportionate to the actual integration scope. The middleware platform costs more than the integration work it is supposed to enable. **Our position**: mid-market companies do not need PI/PO. They need direct integrations using the BAPI/RFC/OData/IDoc protocols, deployed as lightweight services in whatever stack the company already runs (Node.js, Python, Java, .NET). The integration logic lives in code your engineers can read. The deployment is a container or serverless function, not a middleware platform. When is PI/PO actually the right answer? Large enterprises with 20+ integrated systems, regulatory requirements demanding centralized message logging, or companies running multiple SAP instances that need orchestration between them. For everyone else, PI/PO is overhead.
For mid-market SAP integration, the pattern that works: ``` External System (e.g., Salesforce, Shopify, custom app) ↓ HTTPS REST Integration Service (Node.js, Python, or .NET; deployed as container) ↓ RFC / OData / IDoc SAP ECC or S/4HANA ``` The integration service is the only custom code FreedomDev writes. It exposes a stable REST API for the external system to call (or webhooks the external system to call our service when events happen on their side), translates the request into the appropriate SAP protocol, calls SAP, handles the response, and returns to the external system. **Why this pattern works:** - **Stable external interface** — the external system never sees SAP's internal complexity. If you migrate SAP versions, switch from RFC to OData, or refactor internally, the external system does not change. - **Standard observability** — the integration service runs in your existing stack with your existing logging, metrics, and alerting. No SAP-specific monitoring tools required. - **Maintainable by non-SAP engineers** — your existing development team can read, debug, and modify the integration service. SAP-side changes still require SAP expertise, but the integration logic lives outside SAP. - **Easy versioning and rollback** — the integration service is just a service. Deploy via CI/CD, roll back via git revert. Compare with PI/PO deployment cycles measured in weeks.
If you are on S/4HANA (especially S/4HANA Cloud Public Edition), the integration landscape is different from classic ECC: **S/4HANA Cloud Public Edition** restricts direct RFC and BAPI access. Custom development is limited to "developer extensibility" via ABAP RAP (RESTful Application Programming) — you define CDS views, service definitions, and service bindings to expose new OData APIs from cloud SAP. **S/4HANA Cloud Private Edition** preserves more flexibility — RFC, BAPI, and IDoc are still accessible, with restrictions vs on-prem ECC. **S/4HANA on-prem** is closer to ECC: full BAPI/RFC/OData/IDoc access, custom ABAP allowed (with the "clean core" principle encouraging extensions via side-by-side architectures rather than ECC-style modifications). **Practical implications for custom API integration:** - On S/4HANA Cloud Public, build custom OData services via the Custom CDS Views app or ABAP RAP-based developer extensibility. Direct BAPI calls are blocked. - On S/4HANA Cloud Private or on-prem, the classic patterns (RFC, BAPI, IDoc) still work. - The Business Accelerator Hub (`api.sap.com`) is the canonical catalog of standard SAP APIs — check it before custom-developing. We work in all three deployments. The patterns differ; the goal is the same.
SAP integration security is a non-trivial layer that off-the-shelf tutorials gloss over. **Communication users.** In S/4HANA, every external integration should authenticate as a Communication User (created via the Maintain Communication Users app). Communication Users are role-restricted — they can only call the specific APIs assigned to their associated Communication Arrangement. This is the principle-of-least-privilege boundary. **Communication Systems and Arrangements.** Set up via the Maintain Communication Systems and Maintain Communication Arrangements apps in S/4HANA Cloud. These define which external systems are allowed to call which APIs. **Authentication methods.** - Basic auth (username + password) — supported but increasingly discouraged - OAuth 2.0 with SAML bearer assertion — preferred for S/4HANA Cloud - Certificate-based authentication — preferred for high-security on-prem deployments - API keys via SAP API Management proxy — adds a layer for rate limiting and analytics **Network segmentation.** SAP systems sit in restricted network zones. Integration services run in DMZ or application zones with controlled paths to SAP. Direct RFC over public internet is almost never the right answer; we deploy integration services inside the SAP network or use SAP Cloud Connector for cross-network connections. **Audit logging.** Every integration transaction logged at the integration service layer (full request/response with PII redaction) and at the SAP layer (the SAP Audit Log). For regulated industries, this two-layer logging satisfies most compliance audit requirements.
**Pattern 1: Salesforce → SAP Customer and Sales Order Sync** (mid-market manufacturer, 2024) - Salesforce as system of record for opportunities and quotes - On opportunity close-won, sync customer to SAP via `BAPI_CUSTOMER_CREATEFROMDATA1` (or update via `BAPI_CUSTOMER_CHANGEFROMDATA`) - Convert opportunity line items to SAP sales order via `BAPI_SALESORDER_CREATEFROMDAT2` - Sync back SAP order number + estimated ship date to Salesforce - Implementation: Node.js service with node-rfc, deployed as a containerized service in the customer's AWS environment - Timeline: 6 weeks discovery to production **Pattern 2: E-commerce → SAP Order Fulfillment Pipeline** (consumer goods company, 2024) - Shopify Plus as e-commerce front-end - New orders trigger webhook to integration service - Service creates SAP sales order via OData service (S/4HANA Cloud Public Edition) - Inventory availability lookup via OData service against Material Master - Status updates pushed back to Shopify as orders progress through SAP workflow - Implementation: Python service using FastAPI + httpx for OData calls - Timeline: 8 weeks **Pattern 3: Warehouse Management → SAP IDoc Inbound** (logistics-heavy manufacturer, 2025) - Third-party WMS (Manhattan SCALE) handles physical warehouse operations - WMS produces high-volume goods movement transactions (300-800 per shift) - IDoc-based integration with custom IDoc type for WMS movements - WMS calls integration service via REST; service formats IDocs and sends via SAP IDoc Adapter - Implementation: .NET service using SAP NCo, IDoc XML generation, retry queue for failed deliveries - Timeline: 10 weeks **Pattern 4: Data Warehouse Extraction from SAP** (analytics-heavy enterprise, 2025) - Daily and hourly extracts of SAP master data and transactional data into Snowflake - ODP framework (Operational Data Provisioning) for incremental extraction - Direct OData services for some object types, RFC for others - Implementation: Python orchestrated via Airflow, lands data in S3 then loads into Snowflake - Timeline: 12 weeks for initial 20 data objects
The SAP custom API integration market splits into three tiers: - **Global system integrators** (Accenture, Deloitte, IBM, Capgemini) — typically $300-500/hour, designed for large enterprise deployments, sell PI/PO and Integration Suite as the recommended architecture - **Specialized SAP consultancies** (smaller boutiques, $200-300/hour) — usually more flexible than the GSIs but still defaulting to enterprise patterns - **General software development firms with SAP capability** (FreedomDev sits here) — $150-250/hour, build integrations as software rather than middleware configurations, recommend PI/PO only when the project actually warrants it The mid-market sweet spot is the third tier. The GSIs are overscoped; the specialized SAP firms often charge mid-market clients for enterprise patterns they do not need. Hiring a software development team that knows SAP gets you working integrations faster and cheaper, and the deliverable is code your team can maintain.
Schedule a direct technical consultation with our senior architects.
Make your software work for you. Let's build a sensible solution.