In short
Anyone connecting an external system to SAP Business One — an e-commerce store, a satellite management system, a BI tool — runs into three technologies with different purposes: Service Layer, DI API and B1IF. They’re not interchangeable, and picking the wrong one doesn’t show up at quote time — it shows up six months later, in maintenance. This article explains what each one does, when to use which, and the architectural mistakes that keep recurring.
The three integration families for SAP B1
Before choosing, it helps to be clear on what these technologies actually are: not three different ways of doing the same thing, but three tools built for different contexts.
Service Layer
The Service Layer is the REST/OData API of SAP B1: it exposes resources (orders, items, business partners, stock) over HTTP, with session-based authentication. It’s designed to be called remotely — a mobile app, a web frontend, an external system living outside the customer’s network — and doesn’t require components installed on the calling machine. It’s the right technology when the caller isn’t on the same Windows network as the SAP B1 server.
DI API
The DI API (Data Interface API) is a COM/.NET library that runs on the same machine or network as the SAP B1 client: it gives more direct access to B1’s internal business logic (validations, document numbering, some behaviors not exposed by the Service Layer). The constraint is geographic and architectural at once: it’s not meant to be invoked remotely like a public API, but to run close to the B1 installation, typically inside local Windows services or client-side add-ons.
B1IF
B1IF (B1 Integration Framework) isn’t an API to call, but an orchestration engine built around scenarios: you define flows that intercept events in SAP Business One (or external systems) and transform/route them to other destinations, without writing custom code for every step. It’s the right tool when you need to orchestrate multiple steps (validation, transformation, routing) and would rather configure scenarios than maintain ad-hoc code for each one.
How to choose
The right question isn’t “which API is more powerful”, but four concrete questions about where the caller lives and how the integration needs to behave:
- Where does the caller live? If it’s a mobile app, a web frontend, or an external system outside the customer’s network, the Service Layer is almost always the right call. If it’s a service or add-on already running on the same machine or Windows network as SAP B1, the DI API becomes a valid option.
- Does it need realtime, or is batch/event-driven fine? One-off synchronous calls (create an order, read stock) are the natural case for the Service Layer or the DI API. If instead you need to react to events and route/transform data to multiple destinations, B1IF avoids writing custom code for every scenario.
- How deep does the access to B1’s business logic need to be? Some internal behaviors (specific validations, document numbering in certain contexts) are more accessible via the DI API than via the Service Layer.
- Who maintains the integration over time? An integration built with the wrong tool doesn’t show its cost on go-live day — it shows up when it needs to be extended or when a requirement changes, and at that point rewriting it is expensive.
Comparison table
| Dimension | Service Layer | DI API | B1IF |
|---|---|---|---|
| Protocol | REST / OData over HTTP | Native COM/.NET library | Scenario engine, not an API |
| Where the caller can run | Remotely, outside the customer’s network | Same machine/Windows network as the SAP B1 client | B1IF server, typically close to SAP B1 |
| Type of access | REST resources (orders, items, BPs) | Direct access to B1 business logic | Event/transformation orchestration |
| Typical use case | Mobile apps, external web integrations | Local add-ons, Windows services close to B1 | Multi-destination routing, multi-step flows |
| Maintenance complexity | Low if the caller stays stateless | Grows if the service needs to run on multiple machines | Scenario configuration, less custom code |
Common architectural mistakes
A few wrong patterns show up almost identically project after project:
- Using the DI API for a case that should have been the Service Layer. A web or mobile integration built on top of the DI API ends up needing a dedicated server-side component just to “get close” to SAP B1 — complexity that’s avoidable by choosing the Service Layer from the start.
- Synchronous when it should have been asynchronous. Calling the Service Layer synchronously for every single event, when what’s really needed is orchestrating multiple steps or handling retries, leads to fragile integrations: this is the case where B1IF or an application queue would have held up better.
- Duplicating the source of truth instead of reading/writing SAP B1 directly. Building a second database that replicates master data and stock “for convenience” introduces an alignment problem that eventually has to be paid for — the same principle applies to custom integrations and to mobile products alike (we cover this in our article on van sales on SAP Business One).
- Ignoring Service Layer session limits at high volumes. Service Layer sessions have a lifecycle that needs to be handled explicitly: an integration that doesn’t account for it in its design risks intermittent errors under load. (Exact limit values depend on the SAP B1 version and configuration: they need to be verified case by case, not assumed upfront.)
Frequently asked questions
Can I use the Service Layer and the DI API together in the same project?
Yes. They’re not mutually exclusive alternatives: it’s common for an integration to use the Service Layer for remote calls and a local DI API-based component for specific operations that need more direct access to business logic. The key is being explicit about which technology answers which need, not mixing them out of habit.
Do I need B1IF if I already have a developer writing custom integrations?
It depends on how many orchestration scenarios you need and how much they change over time. If the flows are few and stable, custom code can be enough. If the flows grow (more destinations, more transformations, more events to intercept), B1IF reduces the amount of code to maintain for each new scenario.
Does the Service Layer work outside the customer’s network too?
Yes, that’s exactly what it’s designed for: it’s a REST API accessible remotely, with session-based authentication. That’s why it’s the natural choice for mobile apps and web integrations that don’t live on the same network as the SAP B1 server.
Which technology does MTF use in its mobile products?
MTF.Sales.Suite, MTF.Warehouse and MTF.TMS natively integrate SAP Business One through the Service Layer: it’s the consistent choice for products that need to work from mobile devices outside the customer’s network, with SAP B1 as the single source of truth.
What MTF does here
MTF is a SAP Silver Partner and has been implementing and integrating SAP Business One for Italian SMEs since 2017. In our consulting work, we design integration architectures on Service Layer, DI API and B1IF based on the actual project — not a fixed template — and our mobile products (MTF.Sales.Suite, MTF.Warehouse, MTF.TMS) use the Service Layer as their native integration with SAP B1.
If you’re evaluating how to integrate a system with SAP Business One, check out MTF’s SAP Business One services or let’s talk about your specific case.