.png)
SAP Business One Integration Guide
SAP Business One integrates with enterprise systems primarily through its Service Layer OData APIs, with SOAP, attachments, database reads, and selected event notifications available for specific scenarios.
SAP Business One integration options at a glance
SAP Business One provides the Service Layer as its primary modern integration interface, exposing HTTP and OData-based REST operations for business partners, items, documents, payments, attachments, and other objects. DI Server provides SOAP-based integration for selected legacy or specialized scenarios, while webhook subscriptions and broader event mechanisms are version-dependent. OData batch requests, pagination, and filtered queries support controlled synchronization. Authorized SAP HANA or Microsoft SQL Server access may support read-oriented reporting and reconciliation, but transactional writes should use supported APIs. Martini can authenticate through Service Layer sessions, orchestrate workflows, transform payloads, receive supported callbacks, and apply retry and reconciliation controls.
| Integration point | Supported by SAP Business One? | Common use cases | How Martini supports it |
|---|---|---|---|
| Service Layer REST APIs | Yes | The Service Layer is SAP Business One’s primary modern API for retrieving and modifying BusinessPartners, Items, Orders, Invoices, IncomingPayments, JournalEntries, attachments, and other supported objects using OData conventions. | Martini can consume the REST API from workflows, manage request configuration and session state, map payloads, apply business rules, and expose reusable APIs around SAP Business One operations. |
| OData queries and pagination | Yes | Use filtering, selection, expansion, ordering, and pagination to retrieve targeted collections and implement incremental synchronization. | Martini can construct filtered requests, process pages, persist watermarks, and control concurrency for restartable synchronization workflows. |
| SOAP APIs through DI Server | Limited | DI Server provides SOAP-based integration for selected scenarios, especially where an existing interface or operation is not available through the Service Layer. DI API is an SDK rather than a SOAP endpoint. | Martini can consume supported SOAP services, configure authentication and error handling, and route SOAP responses through the same transformation and orchestration workflows. |
| Webhooks and outbound callbacks | Limited | Supported Service Layer versions and deployments can provide notifications for selected business-object events. Coverage, payload detail, authentication, and delivery behavior must be verified. | Martini can receive supported HTTP notifications through an API or workflow trigger, validate the request, retrieve the current object, and process duplicates or retries. |
| Bulk and batch APIs | Limited | Applicable Service Layer versions support OData $batch requests for grouping multiple operations, although batching is not necessarily asynchronous. | Martini can combine pagination, bounded concurrency, batch requests where appropriate, idempotent processing, and retry handling for high-volume workloads. |
| File and attachment APIs | Yes | The Attachments2 object and related Service Layer operations support attachments associated with SAP Business One business objects, subject to deployment and file configuration. | Martini can transfer, validate, associate, and clean up files while handling file limits, duplicate detection, temporary storage, and secure configuration. |
| Database and analytics access | Limited | SAP Business One deployments can use SAP HANA or Microsoft SQL Server. Direct access is appropriate primarily for approved reporting, reconciliation, staging, or analytics reads. | Martini can use supported database connectivity for read-oriented workflows, but transactional writes should be routed through SAP Business One APIs. |
| Service Layer session authentication | Yes | The usual pattern calls /Login with the company database, user name, and password, then uses the returned B1SESSION cookie for subsequent requests. | Martini can store credentials in secrets, establish and renew sessions, protect cookies from logs, and handle expiration or authorization failures. |
How SAP Business One exposes data and business events
SAP Business One REST APIs
The Service Layer provides SAP Business One’s primary HTTP and OData-based interface. It supports retrieval and modification of supported business objects, filtered queries, related-object expansion, actions, and attachment operations. Exact objects and operations vary by release and deployment.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates against the Service Layer, calls the required resource, checks the response, maps the SAP Business One payload to a canonical model, applies business rules, and writes to the target system or returns a controlled API response.
Implementation sequence
SAP Business One Webhooks
Selected SAP Business One Service Layer versions and deployments support webhook subscriptions or event notifications for supported objects and events. Notifications are not universal and may contain only an object key rather than the complete resource.
Martini implementation pattern
Martini implementation pattern: expose a controlled API or workflow trigger, validate the notification and its authentication requirements, retrieve the current SAP Business One object, then process it idempotently. Polling or reconciliation remains necessary for uncovered events.
Implementation sequence
SAP Business One SOAP via DI Server
DI Server provides SOAP-based integration capabilities for selected scenarios and existing interfaces. It is distinct from the DI API SDK and is generally secondary to the Service Layer for new application integrations.
Martini implementation pattern
Martini implementation pattern: configure a SOAP API consumption workflow, send the required request, normalize the SOAP response, and route successful or failed outcomes through shared mapping, retry, and reconciliation services.
Implementation sequence
SAP Business One Batch Operations
Applicable Service Layer versions support OData $batch requests for grouping multiple operations. Batch requests are not necessarily asynchronous, so capacity, response interpretation, and partial-failure behavior must be tested in the target deployment.
Martini implementation pattern
Martini implementation pattern: partition work into controlled batches, submit requests with bounded concurrency, inspect each operation result, and record item-level success or failure for replay and reconciliation.
Implementation sequence
SAP Business One Attachments
SAP Business One exposes the Attachments2 object and related operations through the Service Layer. File size limits, allowed types, attachment directories, and association behavior depend on configuration.
Martini implementation pattern
Martini implementation pattern: receive or retrieve the file, validate size and type, create or locate the attachment entry, associate it with the target object, and remove temporary files after a confirmed outcome.
Implementation sequence
Common SAP Business One integration patterns
Pattern 1: Synchronize business partners to a CRM
When to use this pattern
Use this pattern when SAP Business One owns customer, vendor, or lead master data and another application needs current account and contact information. A scheduled incremental workflow is appropriate when webhook coverage is unavailable or incomplete.
Integration direction
Example Mapping
| SAP Business One Field | Canonical Field | Target Field |
|---|---|---|
| CardCode | externalCustomerId | External_ID__c |
| CardName | name | Account.Name |
| FederalTaxID | taxIdentifier | Tax_Number__c |
| ContactEmployees | contacts | Contacts |
Martini implementation pattern
Martini authenticates to the Service Layer, retrieves BusinessPartners using a modified-date or application watermark, paginates through results, maps addresses and contacts, and applies ownership and duplicate rules. The workflow stores the last successful checkpoint and retries transient failures without creating duplicate CRM accounts.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination and checkpoints
- data mapping
- business rules
- error handling
Pattern 2: Create sales orders from commerce
When to use this pattern
Use this pattern when an external commerce platform receives customer orders that must become SAP Business One Orders. It is useful for controlled order intake where ERP validation must govern customer, item, warehouse, tax, currency, and pricing rules.
Integration direction
Example Mapping
| SAP Business One Field | Canonical Field | Target Field |
|---|---|---|
| order.id | externalOrderId | U_ExternalOrderId |
| customer.email | customerEmail | BusinessPartners.EmailAddress |
| line_items[].sku | itemCode | DocumentLines.ItemCode |
| line_items[].quantity | quantity | DocumentLines.Quantity |
Martini implementation pattern
Martini receives or retrieves the order, validates the customer and item references, checks whether the external identifier has already been processed, and creates the SAP Business One Orders document. It records the returned document number and routes validation, authorization, or uncertain-outcome failures to reconciliation rather than blindly retrying document creation.
Martini capabilities used
- API-triggered workflows
- API consumption
- data mapping
- validation
- idempotency
- business rules
- retry and reconciliation
Pattern 3: Publish inventory availability
When to use this pattern
Use this pattern when commerce or order-management applications require warehouse-aware inventory information from SAP Business One. Scheduled incremental extraction is suitable when event coverage does not provide reliable item or warehouse changes.
Integration direction
Example Mapping
| SAP Business One Field | Canonical Field | Target Field |
|---|---|---|
| ItemCode | sku | inventoryItem.sku |
| WarehouseStock.OnHand | onHandQuantity | inventoryItem.onHand |
| WarehouseStock.Committed | committedQuantity | inventoryItem.committed |
| WarehouseStock.Available | availableToPromise | inventoryItem.available |
Martini implementation pattern
A Martini scheduler retrieves Items and warehouse-level availability using selected fields and pagination, calculates or maps the agreed availability measure, and publishes only changed values. The workflow uses bounded concurrency, checkpointing, and reconciliation to handle missed pages or temporary Service Layer failures.
Martini capabilities used
- scheduler triggers
- REST API consumption
- data transformation
- mapping
- bounded concurrency
- monitoring
- error handling
Pattern 4: Process invoice or payment events
When to use this pattern
Use this pattern where the target SAP Business One release supports notifications for Invoices or IncomingPayments and downstream systems need timely financial status updates. Polling should remain available as a reconciliation fallback.
Integration direction
Example Mapping
| SAP Business One Field | Canonical Field | Target Field |
|---|---|---|
| DocEntry | sourceDocumentId | SAP_Business_One_Document_Id__c |
| DocNum | documentNumber | ERP_Document_Number__c |
| DocTotal | totalAmount | Invoice_Amount__c |
| DocStatus | status | Invoice_Status__c |
Martini implementation pattern
Martini receives the supported notification, validates the callback, retrieves the current document, and applies state and duplicate checks before updating Salesforce. It records event identifiers and document watermarks, retries transient downstream failures, and runs scheduled reconciliation for events that were not delivered.
Martini capabilities used
- webhook consumption
- workflow triggers
- API consumption
- data mapping
- idempotency
- retry handling
- reconciliation
Applications commonly integrated with SAP Business One
SAP Business One can be integrated with adjacent business applications through its Service Layer, supported SOAP interfaces, event mechanisms, and read-oriented database access. The appropriate direction and system of record depend on the customer’s operating model.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize BusinessPartners, opportunities, orders, invoices, and payment status between customer-facing processes and SAP Business One. | Salesforce → Martini → SAP Business One | Martini can expose or consume REST APIs, map Salesforce data to SAP Business One objects, validate CardCode and item references, and maintain external identifiers for safe retries and reconciliation. |
| Shopify | Exchange products, prices, inventory availability, customers, and orders between the commerce platform and SAP Business One. | Shopify → Martini → SAP Business One | A Martini workflow can receive or poll Shopify orders, map line items to SAP Business One item codes, create Orders, and publish inventory or fulfillment updates back to Shopify with duplicate controls. |
| Jira | Create and track work for ERP exceptions, integration failures, order issues, and implementation tasks. | SAP Business One → Martini → Jira | Martini can classify SAP Business One or workflow errors, create Jira issues with sanitized diagnostic context, and optionally process status changes for operational follow-up. |
| ServiceNow | Create incidents or requests for failed postings, authorization problems, integration exceptions, and finance operations. | SAP Business One → Martini → ServiceNow | A Martini error workflow can normalize failures, prevent duplicate incident creation using a correlation key, call ServiceNow APIs, and retain the incident reference for reconciliation. |
| NetSuite | Coordinate customer, item, order, and financial data when both ERP platforms operate across entities, business units, or transition programs. | SAP Business One → Martini → NetSuite | Martini can route objects according to system-of-record rules, transform SAP Business One documents into NetSuite-compatible payloads, and persist cross-system identifiers and processing states. |
| Microsoft Power BI | Provide curated SAP Business One data for financial analysis, inventory reporting, reconciliation, and operational dashboards. | SAP Business One → Martini → Microsoft Power BI | Martini can extract approved read-oriented data through the Service Layer or database access, stage normalized data, and expose or deliver it to a reporting layer used by Power BI. |
| Workday | Exchange selected supplier, employee, cost-center, or finance reference data where Workday and SAP Business One have complementary responsibilities. | Workday → Martini → SAP Business One | A scheduled Martini workflow can retrieve approved Workday reference data, validate mappings, and update supported SAP Business One master or reference objects without bypassing ERP rules. |
| Zendesk | Give support agents customer, order, invoice, and shipment context while allowing approved service-related updates to flow back to operational systems. | SAP Business One → Martini → Zendesk | Martini can retrieve SAP Business One BusinessPartners and document status, map them into Zendesk customer context, and route approved support updates through controlled workflows. |
How to build a SAP Business One integration in Martini
Objective
Establish the Service Layer or supported SOAP connection for the target SAP Business One company database and deployment.
Instructions in Martini
- Confirm the SAP Business One release, API version, host, port, TLS configuration, and company database
- Store user credentials and endpoint configuration in Martini secrets or environment configuration
- Implement Service Layer /Login and protect the B1SESSION cookie from logs
- Confirm the SAP Business One user authorizations for required objects and operations
Objective
Select an event, webhook, API request, or schedule that matches the required freshness and the confirmed capabilities of the SAP Business One deployment.
Instructions in Martini
- Use a Martini API or workflow trigger for inbound transactions
- Use supported SAP Business One webhook notifications only for verified objects and events
- Use scheduler triggers and polling for uncovered or incomplete event scenarios
- Define a reconciliation schedule for missed or delayed changes
Objective
Retrieve complete and current SAP Business One objects while controlling payload size, pagination, and session expiry.
Instructions in Martini
- Use Service Layer filters, selected fields, and expansions where appropriate
- Process collection responses page by page with a stable ordering strategy
- Refresh the session when authentication expires
- Retrieve the current object after a notification rather than relying only on event payload content
Objective
Coordinate validation, enrichment, routing, target writes, and persistence of processing state in a maintainable Martini workflow.
Instructions in Martini
- Separate transport, transformation, business rules, and target-system operations
- Persist external identifiers, SAP Business One keys, checkpoints, and correlation IDs
- Route success, retryable failure, and permanent business failure to distinct paths
- Use reusable workflow or service logic for common authentication and error handling
Objective
Convert SAP Business One objects and documents into the canonical model required by downstream applications without losing business identifiers or relationships.
Instructions in Martini
- Map actual objects such as BusinessPartners, Items, Orders, Invoices, and IncomingPayments
- Preserve CardCode, ItemCode, DocEntry, DocNum, and external transaction identifiers
- Transform addresses, contacts, tax, currency, warehouse, and document-line structures
- Validate required fields, data types, enumerations, and document references
Objective
Ensure that transactions comply with SAP Business One accounting, inventory, authorization, document-state, and duplicate-prevention rules.
Instructions in Martini
- Validate customer and item references before creating documents
- Check warehouse, price-list, tax, currency, payment-term, and sales-person requirements
- Do not assume closed, canceled, or posted documents can be changed
- Use idempotent lookups before retrying an uncertain document creation
Common SAP Business One data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| BusinessPartners | Customers, vendors, and leads used for master-data synchronization and document references. | Salesforce, Shopify, Zendesk, NetSuite, Workday | Martini retrieves or writes supported fields through the Service Layer, maps addresses, contacts, payment terms, and tax information, and uses the business-partner code for deduplication. |
| Items | Inventory and sales item master data, including item references used on sales and purchasing documents. | Shopify, Salesforce, Microsoft Power BI, NetSuite | Martini maps SAP Business One item codes, descriptions, prices, warehouse information, and availability while preserving the ERP identifier. |
| Orders | Sales or purchasing document processing, including order creation and status propagation. | Shopify, Salesforce, NetSuite, Zendesk | Martini validates CardCode, item codes, warehouse, tax, currency, and external identifiers before creating or updating supported documents and reconciling document numbers. |
| Invoices | Accounts receivable or accounts payable document synchronization and financial-status reporting. | Salesforce, NetSuite, Zendesk, Microsoft Power BI | Martini retrieves or creates supported invoices, preserves document references, applies state-aware rules, and avoids updates to closed or posted documents where not allowed. |
| IncomingPayments | Customer payment processing and payment-status propagation. | Salesforce, NetSuite, Microsoft Power BI, Zendesk | Martini maps customer, currency, amount, and document references, validates accounting requirements, and uses idempotency and reconciliation state for retries. |
| JournalEntries | General-ledger postings, accounting integration, and reconciliation extracts. | NetSuite, Microsoft Power BI, finance data stores | Martini can process approved API operations or read-oriented extracts, apply validation and authorization rules, and preserve posting references for audit and reconciliation. |
Authentication and security considerations
Service Layer sessions
The common authentication flow calls the SAP Business One Service Layer /Login endpoint with a company database, user name, and password, then uses the returned B1SESSION cookie for subsequent requests. Session expiration and renewal should be handled explicitly.
Secrets and transport security
- Store credentials, endpoint settings, and sensitive configuration in Martini secrets or environment configuration.
- Use TLS and verify that the Martini runtime trusts the target certificates.
- Never write passwords or session cookies to workflow logs.
- Confirm SAP Business One user authorizations for each company database, object, and operation.
- Do not assume OAuth 2.0 is available for every Service Layer deployment; confirm the target architecture first.
Operational considerations for SAP Business One integrations
Capacity and pagination
Service Layer capacity depends on the deployment, database, concurrent users, and workload. Use bounded concurrency, filtered queries, selected fields, stable ordering, pagination, and off-peak scheduling rather than assuming a fixed public rate limit.
Idempotency and retries
A successful document request can still have an uncertain outcome if the response is lost. Persist external identifiers and processing states, search before creating documents, use backoff for transient failures, and reconcile document numbers after uncertain requests.
Business rules and schema changes
SAP Business One applies accounting, inventory, tax, authorization, pricing, and document-lifecycle rules. Test required objects and properties against the target release and feature pack, handle closed or posted documents carefully, and keep mappings version-controlled.
- Classify authentication, authorization, validation, duplicate, network, availability, and internal SAP Business One errors separately.
- Validate webhook coverage, payload detail, duplicate behavior, and ordering before relying on event-driven processing.
- Use approved database access primarily for reporting, staging, and reconciliation reads.
- Retain enough correlation and document context to replay failures without exposing sensitive credentials.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini provides a maintainable workflow layer around SAP Business One APIs, allowing authentication, retrieval, transformation, business rules, target writes, retries, and reconciliation to be managed as one integration process.
Reusable integration assets
Teams can expose controlled APIs, consume REST or SOAP services, receive supported callbacks, schedule synchronization, and reuse mappings and error-handling logic across BusinessPartners, Items, documents, payments, and attachments.
Operational control
- Persist checkpoints, external identifiers, and correlation IDs for restartable processing.
- Separate retryable transport failures from permanent business-rule failures.
- Monitor workflows and retain structured logs for troubleshooting.
- Adapt mappings and routing as SAP Business One versions, feature packs, and downstream applications change.
Frequently asked questions
SAP Business One can be integrated primarily through the Service Layer, an HTTP and OData-based REST API for business objects and documents. DI Server provides SOAP integration for selected scenarios, while supported versions may provide limited webhook or event notifications. Pagination, batch requests, attachments, and approved read-oriented database access can support additional synchronization and reporting requirements.
Yes. Martini can integrate with SAP Business One by consuming the Service Layer REST APIs, invoking supported DI Server SOAP interfaces, receiving supported callback or webhook notifications, and using approved database reads for reporting or reconciliation. Martini can orchestrate workflows, map data, apply business rules, and manage retries without requiring a documented native connector.
No. A dedicated SAP Business One connector is not required. Martini can use SAP Business One’s confirmed native integration mechanisms, especially the Service Layer REST API, and can also consume supported SOAP interfaces, receive selected notifications, process attachments, or perform approved read-oriented database access.
Lonti does not charge an additional per-connector or per-vendor fee to integrate SAP Business One. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from SAP, infrastructure providers, hosting environments, or other third-party systems based on licensing, usage, and deployment model.
The Service Layer is generally the preferred modern interface for application integrations because it provides HTTP and OData-based access to supported business objects and operations. DI Server SOAP is a secondary option for existing interfaces or capabilities not exposed through the Service Layer. Direct database access should generally remain read-oriented.
Selected Service Layer versions and deployments support webhook subscriptions or event notifications for supported objects and events, but SAP Business One does not provide universal notifications for every object or field change. Coverage, payloads, authentication, retries, and ordering must be verified for the customer’s release, patch level, and deployment. Polling and reconciliation may still be required.
Use filtered and paginated Service Layer requests with a persisted modified-date, document-number, or application-specific watermark. Martini can process pages with bounded concurrency, apply idempotent upsert logic, and use periodic reconciliation to detect missed changes. OData batch requests may help in applicable deployments, but batching is not necessarily asynchronous.
Yes. Martini can expose a controlled API that hides SAP Business One session handling and presents a stable contract to external applications. The façade can validate requests, apply business rules, call the Service Layer or supported SOAP interface, normalize responses, and provide consistent error handling while preserving SAP Business One document references.
Related Martini documentation
SAP APIs
Data Processing
Plan your SAP Business One integration
Use Martini to connect SAP Business One with enterprise applications through Service Layer APIs, supported SOAP interfaces, event notifications, and controlled data workflows.