One of the first architectural decisions on any SAP Business One integration project is which API to build against: the Service Layer or the DI API (Data Interface API). Both can create a sales order or update a business partner. The right choice depends on constraints that often aren’t obvious until you’ve been through a few implementations.
What each one actually is
DI API
The DI API is a COM-based (and, for HANA, also available via a .NET/Java wrapper) library that runs in-process on a machine with the SAP Business One client components installed, typically on Windows. It has been part of SAP B1 since the earliest versions and gives very fine-grained access to business objects, validations, and even some UI-level events through the related UI API.
Service Layer
The Service Layer is a RESTful, OData-based API introduced with SAP B1 9.0, designed to be consumed over HTTP from any platform — a web app, a mobile app, or middleware like n8n — without needing the SAP client installed locally. It authenticates via a login call that returns a session cookie, and business objects are represented as JSON.
Practical differences that matter
Platform independence
This is usually the deciding factor. If the integration needs to run on Linux, in a cloud function, or from a no-code/low-code tool like n8n, the Service Layer is the only realistic option — DI API’s COM dependency ties it to a Windows machine with SAP B1 client components installed and licensed.
Licensing
DI API calls consume a SAP B1 user licence for the session making the calls, same as any other client. Service Layer sessions also require a licensed user, but because Service Layer is stateless-per-request (aside from the session cookie), it’s generally easier to manage integration user licences cleanly and monitor their usage via session timeouts.
Depth of access
DI API has historically exposed some functionality the Service Layer doesn’t cover, particularly around certain legacy objects, some report generation, and low-level UI automation via the UI API companion. This gap has narrowed significantly release over release, but for very old or very niche business objects, it’s worth checking SAP’s compatibility tables before committing to Service Layer only.
Performance under load
DI API’s in-process COM model can be faster for high-volume, tightly-looped operations run from a Windows service sitting close to the SAP B1 server. Service Layer, being HTTP-based, carries more overhead per call but scales more predictably across distributed, cloud-hosted middleware and handles concurrent external clients more gracefully.
Error handling and validation
Both surfaces run the same underlying business logic and validation rules, so a rejected document (say, a sales order that fails a credit limit check) will be rejected by either API. The difference is in how the error surfaces — DI API returns COM error codes and messages that need translating, while Service Layer returns standard HTTP status codes with JSON error bodies, which tends to be easier for developers unfamiliar with the SAP B1 object model to reason about.
How I actually decide
For new integration projects — particularly anything involving cloud middleware, mobile apps, third-party SaaS, or automation platforms like n8n — Service Layer is the default. It’s the direction SAP itself is investing in, it’s easier to secure over HTTPS with proper reverse proxying, and it doesn’t tie the integration to a specific Windows server’s uptime.
DI API still earns its place in a few scenarios: extending or automating the SAP B1 client UI itself (via the UI API), working with older SAP B1 versions where Service Layer coverage is incomplete, or maintaining an existing DI API-based add-on where a rewrite isn’t justified by the project’s remaining lifespan.
Takeaway
Don’t default to whichever API you learned first. For anything new, ask whether the integration needs platform independence, will run outside a Windows/SAP client environment, and needs to talk to modern web or automation tooling — if any of those are true, Service Layer is very likely the right call.
Leave a Reply