Function · Host API Built

Integrate your WMS once.

Every WMS and ERP speaks its own dialect. openWCS exposes one canonical, vendor-neutral Host API — orders, ASNs, SKUs and adjustments in; confirmations out — and keeps the vendor's protocol in a thin adapter. Integrate against the contract, not the integrator.

How it works

One contract in, confirmations back out.

The Host API is mostly a translation layer over order-management, master-data and the transaction log. A host posts work in; it pulls confirmations back as a feed over the same event log that drives inventory.

Orders & ASNs in

Work from the host

Post an outbound order (ship-to, service, route, label template, lines) → an OUTBOUND order; post an ASN / expected receipt → an INBOUND order. The host drives both sides through one surface.

Reference data

SKU sync

Push a list of SKUs by code, each with its unit-of-measure hierarchy and barcodes inline. The host stays the source of reference data: the nested lists are authoritative, so openWCS resolves materials, packaging levels and scanned barcodes to SKUs without a separate import job.

Adjustments

Signed stock deltas

A signed inventory adjustment is appended to the transaction log as a StockAdjusted event; the inventory projection applies the delta — so a host correction flows through the same event spine.

Confirmations (pull)

Cursor feed

Pull confirmations — receipts, picks, shipments, stock changes — as a cursor feed over the transaction log: the events after the cursor plus a next cursor. No host endpoint needed; the host sets the pace.

Confirmations (push)

Webhooks

Register a callback URL and a dispatcher streams confirmations to it, advancing the cursor only past successfully-delivered events — at-least-once, with a failing endpoint retried from its cursor.

Idempotency

Retries are safe

Any host POST may send an Idempotency-Key; a repeat of the same key replays the stored response instead of re-processing — so a host's retry never double-creates an order, ASN or adjustment.

Vendor adapters

SAP & Manhattan translate in.

A vendor doesn't integrate against openWCS internals — it integrates against the canonical Host API. The SAP and Manhattan adapters reshape native messages, resolve items to SKUs, and call the same endpoints any host would.

integration-sap

SAP messages → canonical

Translates SAP orders and ASNs into the Host API, syncs routes to the master-data route catalog, and requests per-shipper dispatch-label barcodes — SAP's protocol stays in the adapter.

integration-manhattan

Manhattan Active → canonical

Translates Manhattan Active orders and ASNs into the same canonical Host API, resolving materials to SKUs — so a second WMS is another adapter, not a second integration surface.

At a glance

Host → canonical API → confirmations.

  SAP / Manhattan adapter ─► (reshape · resolve SKUs) ─►  canonical Host API
  WMS / ERP ───────────────────────────────────────────►  /api/host
                       │  orders → OUTBOUND · ASNs → INBOUND
                       │  SKU upsert → master-data · adjustment → StockAdjusted (txlog)
                       │  Idempotency-Key → replay stored response
                       ▼
            confirmations  ── pull: cursor feed over txlog
                           └─ push: webhook (at-least-once, cursor advances on 2xx)

Open & vendor-neutral

Your integration, on your terms.

The Host API contract is open source. Integrate any host against one surface; add a new WMS as an adapter — and read every confirmation off the event log you already own.