Skip to main content
Talk to an expert
TechnologyWMS

WMS integrations for ecommerce fulfilment.

WMS owns the physical operation: receiving, putaway, pick, pack, dispatch. iWeb integrates ecommerce with the WMS that runs the warehouse, so storefront stock and dispatch promises reflect what is actually possible.
600+
Commerce projects
40+
Engineers · on staff
31
Years · systems behind commerce
1995
Founded
Contents · 6 sections
  1. 01Common problems and patterns.
  2. 02Selected case studies.
  3. 03How this system fits next to commerce, PIM and ERP.
  4. 04Questions we get asked.
  5. 05Clients we build for.
  6. 06Where this fits in the wider estate.
01 · Common problems and patterns

Common problems and patterns iWeb sees.

Stock by location
Real stock by warehouse, depot or branch surfaced to the storefront, with safety thresholds and back-order rules.
Dispatch promises
Cutoff times and delivery promises tied to WMS capacity, not to a static rule in the CMS.
Pick, pack, dispatch
Order flow into the WMS, with confirmations flowing back to update storefront state and notify the customer.
Returns
Returns recorded by the WMS, reflected in stock, with the storefront and finance kept in step.
Multi-location fulfilment
Allocation across multiple warehouses, with the right rules per channel and per customer type.
Operational telemetry
Throughput, error rates and stock accuracy as visible signals, not a quarterly export.
Receiving and putaway
Inbound receipts and putaway events flowing to the storefront so newly landed stock is sellable on the right rhythm.
3PL boundaries
Where the warehouse is run by a 3PL, integration contracts and SLAs are governed at the boundary, not negotiated by ticket.
Carrier integration
Carrier label generation, manifests and tracking events tied to the WMS, with reconciliation back to OMS and storefront.
Inventory accuracy
Cycle counts, adjustment rules and reconciliation against ERP so storefront stock and warehouse stock do not drift.
Returns and refurb
Returns triaged at the WMS (re-sellable, refurb, scrap) with stock and finance kept in step.
Honest WMS-vs-ERP decision
Small operations often run on ERP stock fields alone. iWeb will say so where a dedicated WMS does not earn its place; multi-location, complex pick paths and returns volume are the usual triggers.
02 · Related work
03 · Integration and operational context

How this system fits next to commerce, PIM and ERP.

Where this system lives in the estate
The integration boundary with commerce, PIM, ERP and operational systems named, versioned and observable, not implied by a connector setting.
Catalogue and PIM separation
Catalogue truth lives in PIM. This system reads from PIM rather than maintaining a parallel product record that drifts away from it.
ERP boundary and commercial data
ERP still owns price, stock and accounts. This system orchestrates around the ERP rather than replacing it; the boundary is the design decision.
Storefront and customer surface
How customers see the output of this system on the storefront (search, content, order state, payments) governed with the same rigour as the commerce platform itself.
Real-time vs scheduled sync
Read paths cached at the storefront boundary, writes posted through monitored queues, reference data refreshed on a defined cadence tuned to ERP and PIM load.
Multi-territory and locale handling
Locale-aware behaviour wired in early, not bolted on per project. Translation, currency and per-market rules belong inside the platform rather than the storefront.
Governance and editorial workflow
Approval, completeness and audit workflows that match how the merchant actually edits, releases and runs the estate day to day.
Operational telemetry
Throughput, failures, queue depth and reconciliation reports surfaced as visible signals with on-call ownership, not as silent backlog.
AI under governance
AI features (query understanding, attribute mining, recommendations) scoped to where they earn their place, with decision logs and override controls.
Long-term support and incident response
Releases, incidents and upgrades governed under the same operating model as the wider estate, with a written runbook the on-call team can act on.
Takeover and stabilisation
Inherited builds audited, stabilised and documented before any larger change. The first month on support is deliberately conservative on change.
Honest vendor independence
iWeb names the right tool for the brief rather than the closest partner badge. Decisions are written down with their trade-offs, not assumed.
04 · Questions we get asked

Questions we get asked.

When is a WMS worth the integration effort?

When pick paths, multi-location stock and returns volume need governance the ERP cannot provide. Single-warehouse operations often run on ERP stock fields alone.

Where does the WMS sit in the wider estate?

Underneath the OMS or ERP. The storefront reads stock and dispatch promises from the WMS / ERP boundary rather than from warehouse tables directly.

Which commerce platforms can a WMS integration sit alongside?

The integration pattern is platform-agnostic. iWeb has direct project experience integrating warehouse boundaries with Adobe Commerce and Magento; the same boundary works on other commerce platforms where the architecture supports it.

How is storefront stock kept accurate during a peak?

Stock is cached at storefront read time and refreshed on order events. Drift is alerted rather than absorbed by the storefront.

What should not live in the commerce platform when there is a WMS?

Bin locations, pick rules and packing logic. Those belong with the team that actually picks the order, not in storefront code.

When is a WMS overkill for the brief?

Single-warehouse operations running on ERP stock fields, with simple pick paths and low returns volume. Adding a WMS in that case adds support load without commercial return.

Which WMS systems does iWeb work with?

The decision is client-led. iWeb integrates against the WMS the warehouse already runs or has chosen, with the same boundary principles regardless of vendor.

How does the WMS connect to ERP and OMS?

Through governed boundaries. ERP keeps finance and accounts. OMS owns the fulfilment lifecycle. WMS owns pick, pack and bin operations. The storefront reads stock through the OMS or ERP boundary, not from warehouse tables.

Can iWeb take over an existing WMS integration?

Yes. The team reads the existing integration, allocation rules and incident history first, then writes down what to keep, stabilise or change.

How is warehouse data shown on the storefront?

Through governed availability reads, not direct warehouse queries. Stock is cached at storefront read time and refreshed on order events; drift is alerted rather than absorbed silently.

How does storefront stock stay accurate against the warehouse?

Storefront stock reads from the WMS / ERP boundary, cached at read time and refreshed on order and receipt events. Drift is alerted rather than absorbed.

Can iWeb integrate ecommerce with a 3PL-run warehouse?

Yes. Where the warehouse is run by a third party, integration contracts and SLAs are governed at the boundary rather than negotiated by ticket, with reconciliation back to ERP and OMS.

Accreditations & assurance
Gold Commerce Partner
Specialised in Commerce & AI
ISO certified
27001 · 9001 · 42001
Cyber Essentials Plus
Independently verified security
WCAG 2.2 AA
Accessibility embedded by design
Employee-owned
The same team, long term
Next step

Got a brief on wms?

Send the brief. You'll get a written response from a senior expert on the platform, ERP and operational realities we'd look at first, not a pitch deck.
Talk to an expertor see erp integrations →