Skip to main content
Talk to an expert
TechnologyMarketplaces

Marketplace integrations for ecommerce.

Marketplaces are a sales channel, not a strategy. iWeb integrates ecommerce with marketplaces (Amazon, eBay and trade-specific marketplaces) where the catalogue, margin and operations support it.
600+
Commerce projects
40+
Engineers · on staff
31
Years · systems behind commerce
1995
Founded
01 · Common problems and patterns

Common problems and patterns iWeb sees.

Catalogue syndication
Product data formatted for each marketplace from one governed PIM source, not from spreadsheets.
Listings governance
Listings tracked, expired listings cleaned up, attribute completeness scored per marketplace.
Orders and fulfilment
Marketplace orders flowing into the same OMS/WMS as storefront orders, with the same SLAs.
Stock allocation
Stock allocated across storefront and marketplaces without overselling. Allocation rules are governed.
Pricing per channel
Channel pricing strategy held in the system of record, not embedded in marketplace tooling.
Where the boundary lives
The marketplace integrator is a tool, not a parallel commerce platform. iWeb keeps the system of record clear.
Seller versus first-party
Where the operator also runs a Mirakl-style marketplace, first-party and third-party stock and orders stay distinct in accounting and reporting.
Performance metrics and SLAs
Marketplace performance metrics (dispatch time, cancellation rate) monitored against contractual SLAs, not chased after suspension.
Marketplace-specific compliance
Category restrictions, regulated-product rules and tax handling per marketplace surfaced honestly from the catalogue.
Returns and refunds per marketplace
Returns flows handled per marketplace contract, with refunds reconciled against the original tender and the storefront record.
When not to be on a marketplace
Brand, margin and operational headroom are real reasons to step back. iWeb will say so where the marketplace is the wrong channel.
Operational ownership across teams
Marketplace operations, ecommerce engineering, PIM and finance aligned as one operation with named owners for each handoff and a written runbook the on-call team can act on.
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 does selling on marketplaces make sense?

When catalogue, margin and operational headroom genuinely support it. Marketplaces add channels, not strategy, and they add support load that has to be planned for.

Where should marketplace listings actually live?

In the PIM, syndicated to each marketplace through a governed feed. Listings managed in marketplace tooling drift quickly and are hard to roll back.

Which commerce platforms can a marketplace integration sit alongside?

The pattern applies regardless of platform. iWeb has direct project experience integrating marketplaces with Adobe Commerce and Magento; the same boundary works on other commerce platforms where the integrator supports them.

How is overselling prevented across storefront and marketplaces?

Stock allocation rules across channels are governed in the OMS or ERP. The marketplace integrator consumes allocation; it does not own stock.

Should marketplace orders use the same fulfilment as storefront orders?

Usually yes. Converging on a single OMS / WMS is how SLAs stay consistent across channels.

When is selling on marketplaces a bad fit?

When margins do not absorb marketplace fees, when brand control matters more than reach, or when the operation cannot take on the additional support load. iWeb will say so rather than ship a channel that hurts the business.

Which marketplace integrators does iWeb work with?

The decision is client-led. iWeb has integrated Mirakl, ChannelEngine and direct marketplace APIs on commerce platforms, with PIM as the listing source and OMS or ERP as the allocation source.

How do marketplace orders flow back to the ERP?

Through the same path as storefront orders: the OMS or ERP allocates stock, captures the order and runs reconciliation. The marketplace integrator consumes allocation rather than holding its own.

Can iWeb take over an existing marketplace integration?

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

How much does marketplace integration usually cost?

Bracketed against the integrator chosen, the number of marketplaces in scope, the PIM connection and the support model. iWeb gives honest brackets in scoping rather than a single headline number.

How is overselling prevented across storefront and marketplaces?

Stock allocation across channels is governed in the OMS or ERP boundary. The marketplace integrator consumes allocation; it does not own stock.

When does iWeb advise against being on a marketplace?

Where brand, margin or operational headroom does not justify it. The decision is written down with trade-offs; marketplaces are a channel, not a default strategy.

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 marketplaces?

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 all technologies →