Ellipse Gradient for Header

Körber Integration Guide

Integrate Körber supply-chain applications with enterprise systems through product-specific APIs, batch exchanges, files, EDI, callbacks, and approved data interfaces.

Körber integration options at a glance

Körber is a portfolio vendor, so integration capabilities depend on the selected Warehouse Management, Transportation Management, Order Management, ERP, or Körber One product, edition, and deployment model. Product-specific REST APIs are a primary option for newer environments, while SOAP services may remain relevant for legacy deployments. Supply-chain workloads also commonly use batch or asynchronous processing, scheduled exports, CSV, XML, JSON, EDI, SFTP, and other file exchanges. Selected products may provide webhook-style callbacks or event mechanisms, but universal coverage is not confirmed. Martini can consume documented interfaces, expose APIs, orchestrate scheduled or event-driven workflows, transform data, and securely manage credentials.

Integration pointSupported by Körber?Common use casesHow Martini supports it
REST APIsLimitedNewer Körber cloud and platform-oriented products may expose HTTP APIs for Orders, Shipments, Inventory, Items, Facilities, and other product-specific resources. Resources, versions, and authentication vary by product and deployment.Martini can consume documented Körber REST endpoints, paginate and checkpoint results, map payloads, apply business rules, and expose REST APIs for downstream systems.
SOAP APIsLimitedLegacy or enterprise Körber deployments may provide SOAP or other service interfaces for warehouse, ERP, or partner integrations. A product-specific WSDL and supported version must be confirmed.Martini can consume documented SOAP services when WSDL, endpoint, and authentication details are available, then transform responses into canonical or target-system formats.
Webhooks / outbound callbacksLimitedSelected Körber products may provide event or callback mechanisms, but universal coverage for Orders, Shipments, Inventory, Items, or Facilities is not confirmed.Martini can receive supported webhook-style notifications, retrieve the current resource when the payload is incomplete, and apply deduplication and retry handling.
Bulk / asynchronous / batch APIsLimitedBatch and asynchronous processing is relevant to item imports, inventory synchronization, order and shipment exchanges, carrier or rate updates, and historical or reconciliation exports.Martini can orchestrate job submission and polling where documented, process batches, maintain checkpoints, and route failed rows or files for exception handling.
File and EDI exchangeLimitedWarehouse, transportation, ERP, and trading-partner environments may exchange CSV, XML, JSON, EDI transaction sets, or product-specific flat files through SFTP or managed B2B services.Martini can receive and produce supported file payloads, transform schemas, validate control information, archive processed files, and coordinate acknowledgements.
Database / reporting accessLimitedSelected self-hosted or customer-managed deployments may provide database or reporting access. Direct operational database writes should not be assumed without vendor approval.Where approved, Martini can use JDBC or SQL workflows for supported read-only or reporting use cases while keeping schemas and queries product- and version-specific.
AuthenticationLimitedDepending on the product, Körber integrations may use OAuth 2.0 or bearer tokens, API credentials, Basic Authentication, certificates, mutual TLS, IP controls, or EDI partner security.Martini can store environment-specific credentials and certificates as secrets and use them from workflows and exposed APIs with scoped access controls.

How Körber exposes data and business events

Körber REST APIs

Körber product APIs may expose HTTP resources, but the available objects, operations, pagination model, and authentication depend on the selected product, version, and deployment. REST is a recommended starting point for newer documented interfaces.

Martini implementation pattern

Martini implementation pattern: configure the product-specific endpoint and authentication, invoke the resource from a workflow, page through results or retrieve a changed object, transform the payload, and write it to the target while recording a durable checkpoint.

Implementation sequence

Confirm the Körber product, version, tenant, and API contract
Authenticate with the documented Körber security method
Retrieve or submit the relevant resource
Map the payload to the target model
Apply validation, business rules, and idempotency checks
Write the result and store the processing checkpoint

Körber SOAP services

SOAP or other enterprise service interfaces may remain available in legacy or product-specific Körber deployments. They should be used only after confirming the WSDL, service version, operations, and security requirements.

Martini implementation pattern

Martini implementation pattern: consume the WSDL-defined service, construct the required XML request, invoke the operation with the approved credentials or certificate, validate the response, and transform the result into the target system's model.

Implementation sequence

Confirm the WSDL, endpoint, operation, and supported version
Configure the required SOAP authentication and certificates
Build and send the XML request
Validate the SOAP response and fault handling
Map the response to the canonical model
Route faults and retryable failures to controlled error handling

Körber callbacks and events

Selected Körber products may provide webhook-style notifications, callbacks, queues, or event-broker integrations. Coverage is product-specific and should not be assumed for every Order, Shipment, Inventory, or Item change.

Martini implementation pattern

Martini implementation pattern: expose a secured Martini API or consume the supported event endpoint, validate the notification, retrieve the current Körber object when necessary, and make the downstream write idempotent because delivery semantics must be confirmed.

Implementation sequence

Verify the available event types and delivery semantics
Expose or configure the secured receiving endpoint
Receive and validate the notification
Retrieve the current Körber object when the payload is partial
Deduplicate by object identifier and event timestamp
Write the result and record the event outcome

Batch, files, and EDI

Batch processing and file exchange are common supply-chain integration patterns for item imports, inventory, order and shipment exchanges, carrier updates, historical exports, and trading-partner transactions. Formats and transfer methods vary by product.

Martini implementation pattern

Martini implementation pattern: receive or retrieve the file or batch, validate naming, control records, encoding, and schema, transform each transaction into the target model, archive successful input, and produce acknowledgements or exception reports.

Implementation sequence

Receive the approved file, EDI message, or batch result
Validate filename, control data, encoding, and schema
Parse and map each transaction
Apply business and reference-data validation
Write accepted transactions and isolate rejected rows
Archive the input and publish an acknowledgement or exception report

Scheduled Körber synchronization

When callbacks or events are unavailable, scheduled polling and scheduled file processing can synchronize Körber data. A durable watermark, deterministic pagination, and an overlap window help reduce missed changes.

Martini implementation pattern

Martini implementation pattern: trigger a workflow on a schedule, retrieve changed resources or files, process pages in order, apply an overlap window, and persist the last successful watermark only after downstream writes complete.

Implementation sequence

Start the workflow on an agreed schedule
Read the stored watermark and overlap window
Retrieve changed Körber objects or scheduled files
Process pages or transactions deterministically
Write idempotent updates to the target
Persist the new watermark after successful completion

Common Körber integration patterns

Pattern 1: Synchronize ERP orders to Körber

When to use this pattern

Use this pattern when SAP S/4HANA, Microsoft Dynamics 365, Oracle NetSuite, or another upstream application owns order capture and Körber owns warehouse or transportation execution. The workflow should validate operational references before submitting an order.

Integration direction
SAP S/4HANA
Martini
Körber
Example Mapping
Körber FieldCanonical FieldTarget Field
Order numberorder.externalReferenceKörber order reference
SKU and quantitylines[].itemCode and lines[].quantityKörber order lines
Warehouse or facilityfulfillment.facilityCodeKörber facility
Requested delivery datedelivery.requestedDateKörber requested delivery date
Martini implementation pattern

Martini receives an upstream event, polls the source, or processes a file, then validates customer, address, item, quantity, unit, and facility references. It submits the order through the documented Körber API or file interface, records the Körber identifier, and sends permanent validation failures to an exception process while retrying transient failures with backoff.

Martini capabilities used
  • workflows
  • API consumption
  • file processing
  • data mapping
  • business rules
  • idempotency
  • error handling

Pattern 2: Synchronize Körber fulfillment to customer systems

When to use this pattern

Use this pattern when Körber is the system of execution for Shipments, Deliveries, carrier assignments, or tracking and Salesforce, Shopify, or an ERP requires customer-facing fulfillment status.

Integration direction
Körber
Martini
Salesforce
Example Mapping
Körber FieldCanonical FieldTarget Field
Shipment numbershipment.idSalesforce fulfillment reference
Shipment statusshipment.statusSalesforce fulfillment status
Carrier and tracking numbertracking.carrier and tracking.numberSalesforce tracking details
Delivery timestampdelivery.completedAtSalesforce delivered date
Martini implementation pattern

Martini polls a Körber endpoint or receives a supported callback, retrieves the current Shipment or Delivery when necessary, translates Körber status codes, and updates the target system. The workflow uses shipment identifiers and timestamps to ignore duplicates and can retry rate-limit or network failures without repeating completed writes.

Martini capabilities used
  • scheduled workflows
  • webhook consumption
  • data mapping
  • status normalization
  • business rules
  • retry handling
  • monitoring

Pattern 3: Synchronize Körber inventory to commerce

When to use this pattern

Use this pattern when Körber Warehouse Management is the operational source for available inventory and Shopify or another commerce platform needs facility-level sellable quantities. It is particularly useful when reservations or multiple facilities affect availability.

Integration direction
Körber
Martini
Shopify
Example Mapping
Körber FieldCanonical FieldTarget Field
Item or SKUitem.codeShopify variant SKU
Available quantityinventory.sellableQuantityShopify inventory level
Facility codeinventory.facilityCodeShopify location
Allocation or quarantine statusinventory.availabilityStateShopify update eligibility
Martini implementation pattern

Martini retrieves Inventory and Item data through the documented Körber API, batch interface, or file exchange, excludes damaged, quarantined, or allocated stock according to business rules, maps facilities to commerce locations, and performs idempotent updates. A reconciliation workflow compares quantities and timestamps to detect stale or missed updates.

Martini capabilities used
  • API consumption
  • scheduled synchronization
  • data mapping
  • business rules
  • batch processing
  • reconciliation
  • error handling

Pattern 4: Orchestrate transportation status and exceptions

When to use this pattern

Use this pattern when Körber Transportation Management or Warehouse Management coordinates Loads, Shipments, or Deliveries and carrier, ERP, or customer applications need normalized execution status and exception handling.

Integration direction
Körber
Martini
ServiceNow
Example Mapping
Körber FieldCanonical FieldTarget Field
Load or shipment identifiertransport.executionIdServiceNow correlation reference
Carrier statustransport.statusServiceNow exception status
Facility codeexecution.facilityCodeServiceNow location
Exception reasonexception.reasonCodeServiceNow incident description
Martini implementation pattern

Martini consumes documented Körber APIs, files, or callbacks, normalizes carrier and delivery statuses, applies late, failed, or delivered rules, and creates or updates ServiceNow incidents for material exceptions. Correlation identifiers prevent duplicate incidents, while retryable transport failures are separated from business exceptions.

Martini capabilities used
  • workflows
  • API consumption
  • file processing
  • data mapping
  • conditional routing
  • correlation
  • error handling

Applications commonly integrated with Körber

Körber supply-chain applications can participate in broader enterprise architectures involving ERP, commerce, CRM, carrier, and B2B systems. These are typical integration scenarios rather than universally documented turnkey Körber features; the exact interface depends on the deployed Körber product and edition.

Application Scenario Direction Martini Pattern
SAP S/4HANA Synchronize master data, Orders, Inventory, deliveries, and fulfillment or shipment results between enterprise resource planning and Körber operations. SAP S/4HANA → Martini → Körber Martini can consume SAP and Körber APIs or process approved files, normalize master and transaction data, validate warehouse and item references, and coordinate bidirectional status updates with retries and reconciliation.
Microsoft Dynamics 365 Coordinate order management, warehouse execution, inventory availability, and shipment status across business and logistics processes. Microsoft Dynamics 365 → Martini → Körber A Martini workflow can receive or poll Orders from Dynamics 365, map them to the selected Körber interface, persist correlation identifiers, and return shipment or exception updates to Dynamics 365.
Oracle NetSuite Exchange Orders, Items, customers, fulfillment information, and Inventory with Körber warehouse or logistics applications. Oracle NetSuite → Martini → Körber Martini can orchestrate API or file-based exchanges, apply item, facility, unit, and status mappings, prevent duplicate submissions, and run scheduled reconciliation for missed or failed updates.
Salesforce Provide customer-facing order, fulfillment, delivery, and shipment status while optionally sending selected customer or order information into logistics workflows. Körber → Martini → Salesforce Martini can poll Körber or receive supported callbacks, normalize Shipment and Delivery statuses, enrich them with tracking data, and update Salesforce while deduplicating repeated notifications.
Shopify Send ecommerce Orders to Körber fulfillment and return inventory, fulfillment, and tracking updates to the commerce platform. Shopify → Martini → Körber A workflow can validate Shopify order lines and addresses, submit the appropriate Körber order payload or file, and synchronize facility-level availability and tracking updates back to Shopify.
ServiceNow Create operational incidents or service requests from integration failures, warehouse exceptions, and transportation disruptions. Körber → Martini → ServiceNow Martini can classify API, file, business, and connectivity failures, correlate them to Orders or Shipments, and create or update ServiceNow incidents with controlled retry and escalation logic.
SPS Commerce Exchange purchase orders, advance shipping notices, invoices, and other trading-partner transactions through an EDI gateway. SPS Commerce → Martini → Körber Martini can validate EDI gateway payloads, transform them into the selected Körber API or file format, track control and correlation identifiers, and produce acknowledgements or exception records.

How to build a Körber integration in Martini

Objective

Identify the precise Körber product, edition, deployment, tenant, company, warehouse, and supported interface before configuring connectivity.

Instructions in Martini

  • Confirm the product-specific API, SOAP, file, EDI, callback, or approved database interface
  • Configure environment-specific endpoints, network controls, certificates, and credentials
  • Store tokens, keys, passwords, and certificates in Martini secrets
  • Apply least-privilege access for the required warehouses, facilities, and operations

Objective

Select an event-driven, scheduled, API-led, batch, or file-based trigger based on the mechanism confirmed for the deployed Körber product.

Instructions in Martini

  • Use a secured receiving API for supported callbacks or events
  • Use a scheduler for polling and reconciliation when event coverage is unavailable
  • Define the watermark, overlap window, batch size, and polling frequency
  • Document expected delivery semantics and duplicate behavior

Objective

Receive, retrieve, or submit Körber data using the selected interface while preserving product-specific identifiers and correlation information.

Instructions in Martini

  • Invoke documented REST or SOAP operations with the required authentication
  • Process files, EDI messages, or asynchronous jobs according to the agreed contract
  • Handle pagination, continuation tokens, job polling, and payload-size limits
  • Persist source identifiers and correlation references

Objective

Convert Körber-specific objects and codes into a canonical or target-system model without assuming that portfolio products share identical schemas.

Instructions in Martini

  • Map Orders, Shipments, Inventory, Items, Facilities, Loads, or Deliveries explicitly
  • Normalize dates, time zones, units of measure, statuses, and facility codes
  • Validate required fields and reference data before writing
  • Use versioned mappings for product and release differences

Objective

Apply operational and business rules before creating or updating target objects.

Instructions in Martini

  • Exclude damaged, quarantined, or allocated inventory where required
  • Check stable identifiers and existing processing state for idempotency
  • Route missing references, invalid statuses, and duplicate objects to controlled exceptions
  • Separate permanent validation failures from transient connectivity or rate-limit errors

Objective

Deliver accepted data to ERP, commerce, CRM, carrier, B2B, database, or operational systems and record the outcome.

Instructions in Martini

  • Write through the target system's documented API, file, messaging, or database interface
  • Store target identifiers and processing status
  • Use controlled retries with backoff for transient failures
  • Produce acknowledgements, exception records, or reconciliation results

Common Körber data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
OrdersCustomer, sales, fulfillment, or transportation orders exchanged between commerce, ERP, warehouse, and transportation processes.SAP S/4HANA, Microsoft Dynamics 365, Oracle NetSuite, Shopify, EDI gatewaysMartini validates addresses, lines, quantities, facilities, and references; maps the order to the selected Körber interface; stores correlation identifiers; and handles duplicate or rejected submissions.
ShipmentsShipment execution, carrier assignment, tracking, delivery status, and fulfillment communication.Salesforce, SAP S/4HANA, Shopify, carrier systems, customer portalsMartini normalizes carrier and status codes, deduplicates notifications by shipment and timestamp, enriches tracking data, and publishes or writes the result to target systems.
InventoryOn-hand, available, allocated, lot- or serial-controlled quantities and inventory locations.Shopify, SAP S/4HANA, Microsoft Dynamics 365, Oracle NetSuiteMartini applies availability rules, excludes damaged or quarantined stock when required, maps facilities to target locations, and reconciles missed or stale updates.
Products or ItemsProduct master data including SKUs, units of measure, packaging, and item attributes.SAP S/4HANA, Microsoft Dynamics 365, Oracle NetSuite, commerce platformsMartini validates identifiers and units, transforms item structures, sequences master-data delivery before Orders, and routes invalid references for correction.
Warehouses or FacilitiesDistribution centers, warehouse locations, storage areas, operational sites, and facility-level configuration.ERP systems, commerce platforms, transportation systems, reporting storesMartini maps facility codes and operational scopes, applies tenant or company rules, and uses the mappings to route Orders, Inventory, and Shipments correctly.
Loads or DeliveriesTransportation planning and execution details, depending on whether the integration targets Körber Transportation Management or Warehouse Management.SAP S/4HANA, carrier systems, Salesforce, customer portalsMartini translates planning and delivery statuses, correlates Loads or Deliveries with Shipments, applies late or exception rules, and exposes consolidated status data.

Authentication and security considerations

Product-specific authentication

Körber authentication depends on the product, edition, and deployment. Possible mechanisms include OAuth 2.0 or bearer tokens, API credentials, Basic Authentication in legacy environments, mutual TLS, certificates, IP controls, and EDI partner security.

Least-privilege access

Scope integration identities to the required tenant, company, warehouse, facility, business unit, resources, and operations. Do not assume that a credential valid for one Körber product or operational scope applies to another.

Secrets and network controls

  • Store tokens, passwords, API keys, certificates, and SFTP credentials in environment-specific Martini secrets.
  • Use approved private-network access, IP allowlists, and certificate validation where required.
  • Separate sandbox and production credentials and rotate them according to enterprise policy.

Operational considerations for Körber integrations

Throughput and pagination

Confirm product-specific rate limits, concurrency, batch sizes, payload limits, pagination, continuation tokens, and retry-after behavior. Use controlled backoff and prefer bulk or asynchronous processing for high-volume supply-chain workloads.

Synchronization correctness

Store durable watermarks, use overlap windows, normalize time zones, and apply stable identifiers such as order, shipment, item, facility, or external reference numbers. Use idempotency keys where supported and maintain an integration ledger where they are not.

Schema and status changes

Expect differences between Körber products, releases, cloud environments, and self-hosted deployments. Version mappings, validate new enum values, and maintain explicit mappings for order, shipment, inventory, carrier, facility, unit, cancellation, and exception statuses.

Errors and reconciliation

  • Separate authentication, throttling, network, schema, business-rule, duplicate, and missing-reference failures.
  • Retry transient failures with backoff but do not repeatedly retry permanent validation errors.
  • Archive processed files and maintain acknowledgements for file or EDI exchanges.
  • Use reconciliation workflows to compare counts, identifiers, statuses, and timestamps across systems.

Why use Martini instead of scripts or point-to-point integrations?

Reusable orchestration

Martini centralizes workflows that consume Körber APIs, process files, receive supported callbacks, and coordinate ERP, commerce, CRM, carrier, and B2B systems. This avoids duplicating product-specific logic across point-to-point scripts.

Controlled transformation

Mappings, validation, status normalization, facility routing, and business rules can be managed explicitly for the selected Körber product and version. Martini can also expose a stable API façade when downstream consumers should not depend directly on Körber interfaces.

Operational reliability

Scheduled synchronization, checkpointing, idempotency, retries, exception routing, logging, and reconciliation provide a maintainable operating model for high-value Orders, Shipments, Inventory, and master-data flows.

Deployment flexibility

Martini supports API-led, event-driven, scheduled, batch, file, messaging, and approved database-oriented patterns, allowing the integration design to match the actual Körber deployment instead of forcing a single connector model.

Frequently asked questions

How can Körber be integrated with enterprise systems?

Körber is a portfolio of products, so integration depends on the selected application and deployment. Common mechanisms include product-specific REST APIs, legacy or product-specific SOAP services, batch and asynchronous processing, CSV, XML, JSON, EDI, SFTP or other file exchange, and selected callbacks or event mechanisms. Approved reporting or database access may also be available for some self-hosted deployments.

Can Martini integrate with Körber?

Yes. Martini can integrate with Körber by consuming documented product-specific REST APIs or SOAP services, processing files and EDI exchanges, receiving supported callbacks, and orchestrating scheduled synchronization. Martini can transform Orders, Shipments, Inventory, Items, Facilities, Loads, and Deliveries for downstream systems.

Do I need a connector to integrate Körber with Martini?

No. A dedicated Körber connector is not required. Martini can use the selected Körber product's confirmed native APIs, SOAP services, callback mechanisms, files, EDI exchanges, authentication methods, or approved database and reporting interfaces.

Is there any extra Lonti cost to integrate Körber with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Körber. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Körber, cloud infrastructure, EDI providers, or other third-party systems depending on subscriptions, usage, and deployment model.

Which Körber integration methods should architects use?

For new implementations, start with the documented REST API or supported batch and asynchronous interface for the specific Körber product. Use SOAP where a legacy service is required, and use files or EDI where the product or trading-partner process depends on them. GraphQL is not confirmed as a portfolio-wide Körber capability.

Are Körber webhooks or events available?

Selected Körber products may support webhook-style notifications, callbacks, queues, or event-broker integrations, but universal coverage is not confirmed. Verify event types, payload completeness, authentication, filtering, and delivery semantics for Orders, Shipments, Inventory, Items, or Facilities before selecting an event-driven design.

How should Körber data synchronization work when events are unavailable?

Martini can run scheduled workflows that poll documented APIs or process scheduled files. The workflow should paginate deterministically, store a durable last-successful watermark with an overlap window, apply idempotent writes, and run reconciliation to identify missed, stale, or inconsistent Orders, Shipments, or Inventory updates.

Can Martini expose an API façade for Körber?

Yes. Martini can expose a secured REST API that accepts data from Körber or an intermediary service, validates and transforms the payload, applies business rules, routes it to workflows or target systems, and returns a controlled response. The façade can shield consumers from product-specific mappings and version changes.

Related Martini documentation

API Integration

Events

Data Processing

Security

Operations

Build a maintainable Körber integration with Martini

Use Martini to connect the specific Körber product in your environment with enterprise systems through documented APIs, files, events, and approved data interfaces. Design the workflow around your product version, deployment model, security requirements, and operational data flows.

EXPLORE MARTINI
BOOK A DEMO