Companies running SAP Business One already keep items, stock, contract prices and documents in one reliable place. More than 83,000 businesses use the system across over 170 countries (SAP News 2025), and around 1.2 million users work with it every day (SAP News 2025). As soon as an online shop is added, the question arises how the two systems talk cleanly to each other. For a long time this ran through the DI-API, a COM-based programming interface. Today the Service Layer is the recommended path: a REST server that follows the OData standard and exchanges data as JSON (SAP Help). This guide shows how to connect your shop to SAP Business One through the Service Layer, what authentication sits behind it and how to keep stock and contract prices consistent with the ERP as the leading source.
Key takeaways
- The Service Layer is the modern REST/OData interface of SAP Business One and, for web, mobile and cloud integrations, replaces the older, COM-based DI-API (SAP Help).
- It exchanges data as JSON and follows the OData standard in versions 3.0 and 4.0; since Feature Package 2405 OData v3 is deprecated and v4 is the primary protocol (SAP Help).
- Authentication uses either a session login with the B1SESSION and ROUTEID cookies or, since version 10.0 FP 2305, OAuth 2.0 and OpenID Connect (SAP Learning). Sessions should be reused, not reopened per request.
- The ERP stays the leading source: stock, contract prices and documents are kept in SAP Business One, the shop reads them through the Service Layer and reports orders back.
- Integration costs range from around 5,000 to over 150,000 US dollars depending on the approach (WebSolutions NYC 2026); pre-built connectors are cheaper, a tailored Service Layer development more expensive but a precise fit.
Why the Service Layer Replaces the DI-API
The DI-API has accompanied SAP Business One for many years. It is a COM-based programming interface for .NET and is used mainly by add-ons that run directly on the machine with the SAP client (SAP Help). For installed desktop extensions it is still sensible. For a shop integration, however, it brings drawbacks: it relies on the Microsoft SQL edition and Windows, couples tightly to the installed environment and is harder to scale across multiple processes. Anyone connecting an online shop, a mobile app or a cloud service runs into limits with it.
The Service Layer was created for exactly these cases. It is the modern REST interface of SAP Business One, standardised, well documented and able to read and write without a COM bridge (SAP Help). Because it speaks open web standards, almost any programming language can address it, from PHP in the Shopware backend to a dedicated integration service. Whether a direct connection or a middleware between shop and ERP is the better choice depends on scope; the article REST API or middleware explores that trade-off.
REST and OData
The Service Layer follows the OData standard. Resources such as items, business partners and orders are addressed through clear URLs.
Read and Write
Read stock and prices, write orders and documents, all through the same interface without a COM bridge.
Secure Login
Session login with the B1SESSION cookie or OAuth 2.0 and OpenID Connect from version 10.0 FP 2305 (SAP Learning).
Platform-independent
Any language with an HTTP client can address the Service Layer, from the shop backend to a dedicated service.
Scalable
Multiple parallel connections and load balancing via the ROUTEID cookie instead of a single COM session.
Filter and Select
With $filter, $select and $expand the Service Layer returns only the fields the shop actually needs.
What the Service Layer Technically Is
Technically the Service Layer is an HTTP server that runs alongside SAP Business One and exposes the system's business objects as OData resources (SAP Help). An item is reachable at an address like /b1s/v2/Items('A0001'), a business partner at /b1s/v2/BusinessPartners, an order at /b1s/v2/Orders. Responses come back as JSON, and requests to create or change data also go in as JSON. OData query parameters narrow the response precisely: $select fetches only single fields, $filter limits the records, $expand pulls in related objects at once. This keeps the transferred data small and the connection fast.
The Service Layer comes in two flavours. Version 1 is based on Java and delivers OData in version 3.0, version 2 uses .NET Core and OData 4.0 (SAP Business One Blog). Since Feature Package 2405 OData v3 is deprecated, so version 4 is the primary protocol (SAP Help). For new integrations the v2 route under /b1s/v2/ is therefore the right choice. It is best to fix the exact field naming between ERP and shop early so that later corrections are avoided.
POST /b1s/v2/Login
Content-Type: application/json
{ "CompanyDB": "SBODEMO_EN", "UserName": "shopsync", "Password": "***" }
# Response sets the B1SESSION and ROUTEID cookies
GET /b1s/v2/Items('A0001')?$select=ItemCode,ItemName,QuantityOnStock
Cookie: B1SESSION=...; ROUTEID=...Authentication: Session Login and OAuth 2.0
Before the shop retrieves data, it logs in to the Service Layer. With the classic session login, the integration sends the company database, user and password to the /Login endpoint and receives the B1SESSION and ROUTEID cookies in return (SAP Learning). The B1SESSION cookie identifies the session; the ROUTEID cookie makes sure that, in load-balanced environments, follow-up requests hit the same node. These cookies are sent with every further request.
What matters is to reuse the session rather than authenticate per request (SAP Learning). An integration that opens a new session for every stock lookup burdens the system unnecessarily and quickly becomes slow. Better is a session cache that holds the B1SESSION cookie and only re-authenticates once the session has expired. Since version 10.0 FP 2305 the Service Layer additionally supports OAuth 2.0 and OpenID Connect (SAP Learning), which eases connecting to a central user directory. How tokens are stored and renewed securely is explored in the article on OAuth 2.0 and token security.
Pool Your Sessions
Stock with the ERP as the Leading Source
The most important rule of any ERP integration is: there is exactly one leading source. Stock, item master data and prices are kept in SAP Business One, the shop reads them through the Service Layer and reports orders back. If the shop keeps its own, competing inventory, contradictory availability and permanent manual reconciliation arise. 61 percent (Bitkom, Digitalisation of the Economy 2025) of companies cannot fully exploit their data potential because information sits in unconnected systems, and this is exactly the effect that hits a poorly planned shop integration.
The Service Layer itself does not send active notifications to the shop; it answers requests. For up-to-date stock this means fetching the changed records at short intervals (delta sync) or evaluating events in the ERP through a complementary mechanism. Whether a tight polling cadence or an event-driven link fits better is weighed up in the article webhooks versus polling. With several warehouses an aggregation logic is added that consolidates store-level and central stock; this is explored in the article on inventory synchronization across multiple warehouses. A proven reference for the setup is real-time synchronization between SAP and Shopware.
| Criterion | DI-API | Service Layer |
|---|---|---|
| Technology | COM library for .NET | REST server following OData |
| Data format | COM objects | JSON |
| Platform | Windows, MS SQL edition | platform-independent, HANA edition |
| Use | installed add-ons | web, mobile, cloud |
| Login | local connection | session login or OAuth 2.0 |
| Scaling | bound to the environment | multiple connections, load balancing |
Contract Prices and Customer-Specific Prices
In B2B the price is rarely the same for everyone. SAP Business One knows price lists, special prices per business partner and quantity-based tiers. The Service Layer exposes this price determination through the corresponding objects, so the shop can show the correct, customer-specific price instead of a single list price for all. The logged-in business customer then sees exactly the terms stored in the ERP, and the integration becomes an extension of the contracts maintained in the ERP.
Prices should not be hard-coded in the shop but drawn from the ERP and cached with care. Too long a cache shows outdated terms, too short a one burdens the Service Layer. In practice a cache with targeted invalidation works well, triggered as soon as a price list changes. How customer-specific prices are synchronized from the ERP and cached sensibly is described in detail in the article on customer-specific prices from the ERP. The same principle of one source applies to the underlying inventory system.
Robust Integration and Operation
An integration is only as good as its behaviour in the error case. Network outages, expired sessions or a briefly unreachable Service Layer must not cause an order to be booked twice or lost. Two principles help: idempotency ensures that a document sent multiple times is created only once in the ERP, and a retry strategy with growing wait times absorbs temporary faults. These patterns are explored in the articles on idempotency and retry strategies and on error handling in interfaces.
- Define the leading source: Stock, prices and documents belong in the ERP; the shop reads and reports rather than maintaining its own truths.
- Build a session cache: Reuse the B1SESSION cookie and only re-authenticate on expiry.
- Fetch only needed fields: Use $select and $filter to keep the response small and spare the Service Layer.
- Write idempotently: Give documents a unique reference so a repeated send does not create a duplicate.
- Catch errors: Plan for retries with growing wait times and a store for permanently failed operations.
Migration from DI-API and Legacy Systems
Many businesses now face the question of how to replace an existing DI-API connection. Moving to the Service Layer pays off when a shop, an app or a cloud service is added or when the old connection is hard to maintain. It is important not to simply carry over the data model, but to set up the field mapping anew and cleanly. Anyone also coming from an older SAP system will find the migration steps in the article on the SAP ECC end of maintenance in 2027.
The Service Layer approach is not a special case of SAP Business One but follows the same idea as modern cloud ERP interfaces: an open, standardised API as the gateway to the leading system. Anyone also running Microsoft Dynamics will find the comparable path via OData and the Data Management Framework in the article on Dynamics 365 Finance integration. And where large data volumes are involved, it is worth looking at API limits and bulk imports so that a full sync does not slow down the Service Layer.
Cost, E-Invoicing and Approach
What does such an integration cost? That depends heavily on the approach. Across all variants the range runs from around 5,000 to over 150,000 US dollars (WebSolutions NYC 2026). Pre-built connectors start at about 5,000 to 15,000 US dollars for setup (ERP Research 2026), a middleware platform often lies at 10,000 to 30,000 US dollars to introduce (ERP Research 2026), and a fully tailored Service Layer development at 50,000 to 150,000 US dollars (WebSolutions NYC 2026). What drives the figure is the complexity of the pricing logic and the number of connected processes; an overview of the services is given on the SAP integration page and the pricing overview.
Another reason to connect ERP and shop cleanly now is e-invoicing. Since 1 January 2025 every domestic company in Germany must be able to receive e-invoices (German Federal Ministry of Finance). From 1 January 2027 the sending obligation applies to companies with more than 800,000 euros in prior-year revenue, and from 1 January 2028 to all others in B2B (German Federal Ministry of Finance). Anyone already drawing documents from SAP Business One through the Service Layer can generate structured formats such as XRechnung and ZUGFeRD directly from the leading system. For more complex landscapes a custom interface or middleware helps, and for the clean separation of core system and extension the article on the SAP Integration Suite and clean-core connection is worth reading.
- Check systems and versions: Survey the SAP Business One version, the Service Layer route (/b1s/v2/) and the shop's interface.
- Define the data model: Determine the leading source and document the field mapping between ERP and shop.
- Set up authentication: Choose session login or OAuth 2.0 and build the session cache.
- Connect core processes: Items, stock, contract prices, orders and documents first, further channels afterwards.
- Test and go live: Run through error cases, peak loads and pricing scenarios, then go live with close monitoring.
One Source, Many Channels
An interface is not a one-off project but an operation. Log in to the Service Layer cleanly, query it precisely and plan for errors, and you connect the shop to SAP Business One reliably for the long term.