Skip to main content
Talk to an expert
OnBuy logo

OnBuy marketplace integration for ecommerce

Inventory and orders aligned across OnBuy and your store OnBuy orders flow directly into your fulfillment workflow while product data, stock and pricing stay synchronised across channels. Works with Adobe Commerce, Magento Open Source, Shopify Plus, BigCommerce and other storefronts.

Also searched as: marketplace connector, feed integration, channel plugin, app.

OnBuyiWeb integration layeryour storefront
Talk to an expertSee the estate map ↓
Works with - Adobe Commerce · Magento Open Source · Shopify Plus · BigCommerce · Other storefronts
On this pageGet a brief reviewed
01 · What you get

What a OnBuy integration gives you.

Stock and pricing accuracy

Inventory and pricing stay in sync across your primary store and OnBuy. Overselling is eliminated because stock is governed by your ERP and published atomically to all channels.

Order fulfillment speed

OnBuy orders land in your existing fulfillment workflow within minutes. Picking, packing and dispatch staff see unified queues across all channels without manual order entry.

Reduced channel operational overhead

Product and order management happens once in your commerce estate. OnBuy data flows automatically, freeing teams to focus on channel growth rather than manual catalog upkeep.

Customer clarity on delivery

Shoppers see accurate tracking and delivery updates on OnBuy. Dispatch confirmations and carrier details post back automatically so there is no tracking gap between OnBuy and your systems.

Multi-channel revenue insight

Orders from OnBuy flow into your analytics warehouse with channel attribution. You can measure OnBuy performance separately and compare unit economics against your primary store.

02 · When it's worth it

Where a OnBuy integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Publishing product catalog and real-time stock levels to OnBuy sellers portal
Ingesting orders from OnBuy into commerce and ERP systems for fulfillment
Synchronising pricing and promotional rules across OnBuy and primary commerce channel
Managing OnBuy-specific product attributes, descriptions and images
Tracking dispatch confirmations and delivery status back to OnBuy platform
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

OnBuy feed format constraints

OnBuy accepts product feeds only in specific formats and field mappings. Custom attributes or extended metadata may not transmit without custom field configuration or feed transformation.

Channel-specific pricing rules

OnBuy has limited support for complex pricing logic like tiered discounts, bundle pricing or customer-specific rules. Price must often be pushed as a flat value per SKU.

Partial product attribute coverage

OnBuy category taxonomies and required attribute sets differ from your primary commerce platform. Mapping gaps mean some product enrichment may not sync or display on OnBuy listings.

Order metadata limitations

OnBuy order payloads contain essential transaction data but may lack extended order attributes, custom fields or sub-order context that your OMS or ERP relies on.

Tracking and status update latency

OnBuy does not always accept rapid tracking updates or status changes. Batch processing or defined update windows may be required to avoid API rate-limit errors.

04 · The real work

Stock accuracy and order latency are where channel integration success is measured; if inventory publishes stale or orders stall in a queue, the channel is neither trustworthy nor profitable.

05 · Where it sits

Where this integration sits in your estate.

OnBuy holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.

Built for your platform, not a specific one. OnBuy integrates with any ecommerce core through the same contract.

System of record
Source / owner
OnBuy
Marketplace channel connector and order ingestion
  • OnBuy account and seller configuration
  • Product feed format and field mapping
  • Order receipt and validation rules
  • Tracking and dispatch confirmation workflow
  • Channel-specific pricing overrides
iWeb integration layer
Customer-facing commerce
Commerce platform
Adobe CommerceMagento Open SourceShopify PlusBigCommerceOther storefronts
  • Primary product catalog and PIM
  • Stock and inventory governance
  • Pricing and promotional rules
  • Order management and fulfillment
  • Customer and account data
Connected neighbours
Integration layer
ERP
System of record for stock availability, base pricing and order acknowledgement. Integration publishes inventory and pricing to OnBuy from ERP, ingests orders back into ERP.
Integration layer
PIM
Source of product names, descriptions, images and attributes. Integration transforms PIM data into OnBuy feed schema and handles attribute mapping gaps.
Integration layer
OMS / Order management
Destination for OnBuy orders. Integration validates, enriches and routes orders from OnBuy into the order management platform for fulfillment.
Integration layer
WMS / Fulfillment
Source of dispatch confirmations and tracking. Integration polls fulfillment for dispatch status and posts tracking and delivery updates back to OnBuy.
Integration layer
Returns management
Handles OnBuy return requests as RMAs. Integration captures return reason and converts refund decisions from returns system into OnBuy credit notes.
Two-way sync where relevant
06 · Surrounding systems

Systems this integration usually sits next to.

Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.

Ecommerce platforms (examples)
  • Adobe Commerce
  • Magento Open Source
  • Shopify Plus
  • BigCommerce
  • Other storefronts
Surrounding systems (examples)
  • PIM (product catalog source)
  • ERP (inventory and pricing source of record)
  • OMS or order management
  • WMS (fulfillment and dispatch)
  • Returns management (RMA)
  • Analytics warehouse
  • Payment gateway
Not sure?

Not sure if this works with your stack?

Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.

07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into SALES CHANNELS & COMMERCE & ERP
↔BOTH WAYS
Product catalog to OnBuy: Product names, descriptions, images, attributes and SKUs flow from your PIM or commerce platform to OnBuy to create or update live listings
Changes to product data trigger updates to the marketplace feed.
Inventory and pricing sync: Stock levels and pricing rules publish from your ERP or commerce system to OnBuy so listings reflect current availability and cost
Real-time or near-real-time updates prevent overselling.
Orders from OnBuy: Customer orders placed on OnBuy are transmitted into your commerce platform or OMS as new sales records with customer, line item and delivery details captured.
Order and fulfillment instructions: Validated OnBuy orders flow into your ERP system to trigger picking, packing and invoice generation
Fulfillment status and tracking updates flow back to OnBuy.
Returns and refunds: Return requests initiated on OnBuy feed into your RMA or returns management process
Refund confirmations and resolution status post back to OnBuy to close the return loop.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Feed design and mapping

    We map your product attributes, categories and enrichment to OnBuy's feed schema. Custom transformations handle naming, image resizing and attribute translation so your catalog publishes cleanly.

  2. 02
    Stock and pricing governance

    We design the stock and pricing ownership model so your ERP is the system of record and OnBuy receives atomic updates without gaps or double-publishes. Pricing rules, holdbacks and promotional windows are defined upfront.

  3. 03
    Order ingestion and validation

    Orders from OnBuy are ingested, validated against your address and payment rules, and routed to your OMS or ERP with full order context. Duplicates are prevented and exceptions are queued for review.

  4. 04
    Fulfillment and tracking closure

    We embed fulfillment triggers and tracking updates so dispatch confirmations and carrier events post back to OnBuy without manual intervention. Returns and refunds close through the same integration.

  5. 05
    Monitoring and incident response

    We provision dashboards showing feed health, order volumes, API errors and data freshness. Alerts surface stale inventory, failed order ingestions or tracking sync breakages so your team can respond before customers notice.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataProduct catalog and listing data
Source / ownerPIM or commerce platform
Maintained byContent and merchandising teams
NotesProduct data is governed centrally and pushed to OnBuy via feed. OnBuy-specific enrichment (category overrides, extended descriptions) is maintained by channel team.
DataChannel-specific inventory and stock allocation
Source / ownerERP
Maintained byInventory and operations teams
NotesStock availability is owned by ERP and published atomically to OnBuy and primary channel. Holdback or channel-specific buffers are configured once and applied by integration logic.
DataPricing and promotional rules
Source / ownerERP or pricing engine
Maintained byCommercial and finance teams
NotesBase price and promotional discounts are managed centrally. OnBuy pricing rules are published by integration and overrides are made in the pricing system, not on OnBuy directly.
DataOnBuy orders and order line items
Source / ownerCommerce platform or OMS
Maintained byOperations and fulfillment teams
NotesOrders ingested from OnBuy become transactions of record in commerce or OMS. Order status, fulfillment and returns are updated in the order system, then posted back to OnBuy.
DataDispatch confirmation and tracking
Source / ownerWMS or fulfillment system
Maintained byFulfillment and logistics teams
NotesDispatch events and carrier tracking are captured in WMS. Integration polls WMS for status changes and posts tracking back to OnBuy so customers see current delivery status.
DataReturns and refunds
Source / ownerERP or OMS
Maintained byReturns and customer service teams
NotesReturn requests from OnBuy create RMAs in the returns system. Refund decisions and credits are issued by ERP. Integration posts refund confirmation back to OnBuy to close the return.
DataIntegration transport and exception handling
Source / ownerIntegration platform
Maintained byIntegration team and ops
NotesFeed files, API calls and error queues are owned by the integration layer. Data latency SLAs, retry logic and fallback behaviour are designed and monitored by integration governance.
10 · Experienced integrator

Built this before

iWeb has designed and operated OnBuy integrations across multiple estate configurations. We understand how OnBuy fits alongside primary commerce platforms, ERP systems and fulfillment workflows, and where governance and data ownership boundaries are typically ambiguous.

We have integrated OnBuy with multiple ERP systems (Sage, NetSuite, Infor) and understand how to manage stock synchronisation and order routing without overselling or losing orders.
We know OnBuy's feed schema, category taxonomy constraints and API rate limits. We design feed transformations and retry logic that handle OnBuy schema updates and seasonal traffic spikes.
We understand the order ingestion patterns: how OnBuy orders land, what fields are guaranteed and which are optional, and how to validate and enrich them before passing to your OMS.
We design the fulfillment closure loop so dispatch confirmations and tracking updates post back reliably, and we monitor for stale or failed tracking so customers see accurate delivery status.
We provision owned governance for channel pricing, inventory reserves and returns workflows so your teams know exactly who maintains each piece of the OnBuy integration across launch and beyond.
11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Verify stock on OnBuy matches your ERP availability within your SLA after each publish cycle.
Confirm OnBuy orders appear in your OMS within 10 minutes of purchase and contain all required address and line-item data.
Test price publication: update a price in your ERP and confirm it appears on OnBuy within your defined sync window.
Validate fallback behaviour: disconnect OnBuy API and confirm your primary store and ERP continue operating without degradation.
Confirm dispatch confirmations and tracking numbers posted from your WMS appear on OnBuy within 30 minutes.
Test return request flow: initiate a return on OnBuy and verify it creates an RMA in your returns system with correct reason code.
Verify monitoring and alerting: confirm dashboards show feed publish lag, order ingestion failures and API error rates with alert thresholds.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Overselling across OnBuy and primary store

If inventory updates to OnBuy lag behind sales on your primary channel, the same stock can be sold twice. This happens when stock is published in batches or when OnBuy caches inventory for hours.

Product data loss on channel-specific fields

OnBuy requires category codes and attributes that your primary store does not use. If mappings are not defined or tested, products publish incomplete or in wrong categories, harming searchability.

Orders duplicated or lost in ingestion

If order ingestion is not idempotent, retries on API timeouts can create duplicate orders in your ERP. If error handling is weak, orders can stall in a queue and never reach fulfillment.

Tracking updates silent-fail back to OnBuy

OnBuy API changes or rate limits can block tracking updates. If failures are not monitored, customers see no shipping progress on OnBuy while your WMS has already dispatched the goods.

Returns and refunds reconciliation drift

Return requests from OnBuy may not sync with your RMA system if return reason codes do not map. Refund confirmations may not post back if your ERP credit process does not align with OnBuy's timeline.

OnBuy API downtime breaking checkout

If stock validation requires real-time OnBuy API calls during checkout on your primary store, OnBuy outages can block sales. Fallback logic must allow sales to proceed with cached stock.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about OnBuy integrations.

How do we prevent selling the same stock on OnBuy and our primary channel?

Stock is published from your ERP as a single source of truth. The integration pulls available inventory and publishes it atomically to OnBuy and your primary store. Holds for reserved orders or in-transit stock are applied before publication so both channels see the same availability.

What happens to OnBuy product data that does not fit our PIM categories?

We map your product taxonomy and attributes to OnBuy's category structure during setup. Fields that OnBuy requires but your PIM does not track (e.g. brand, condition, warranty) are either filled with defaults or maintained by a channel-specific lookup table. Missing data is logged so merchandisers can enrich it.

How long does it take for an OnBuy order to reach our fulfillment team?

Orders are ingested and validated within minutes of purchase on OnBuy. Once validated, they flow to your OMS or ERP and appear in your picking queue. Total latency is typically 5-15 minutes depending on your validation rules and fulfillment system polling frequency.

Can we apply different pricing on OnBuy than on our primary store?

OnBuy pricing is published from your ERP or pricing engine, so it reflects your primary pricing by default. If you want OnBuy-specific pricing, it must be configured in your pricing system as a channel override. Manual price changes made directly on OnBuy are not recommended as they will be overwritten on the next sync.

What happens if OnBuy is unavailable when a customer tries to buy on our primary store?

If real-time stock validation against OnBuy is not enabled, your primary store operates independently and stock sync happens asynchronously. If you do require live validation, the integration can fall back to cached inventory and reconcile stock after connectivity returns.

How do we handle returns that start on OnBuy but need to go through our RMA system?

Return requests from OnBuy are automatically converted to RMA records in your returns system. Your team processes the return following your standard RMA workflow. Once resolved, the refund is issued in your ERP and the integration posts the resolution back to OnBuy so the customer sees the status update.

How do customers see delivery tracking on OnBuy?

Once your fulfillment or WMS generates a dispatch confirmation and tracking number, the integration polls your WMS or fulfillment system and posts the tracking details to OnBuy. OnBuy displays this information to the customer. Tracking updates continue to sync so customers see current delivery progress.

What if our product names or images change after they are published to OnBuy?

Changes to product data in your PIM or commerce system trigger feed updates. The integration re-publishes changed products to OnBuy at the next scheduled sync or on-demand refresh. OnBuy listings are updated with new names, images and descriptions.

Who owns the decision to publish or unpublish a product on OnBuy?

Publication is controlled by a flag or attribute in your PIM or commerce platform. Merchandising or channel teams set this flag, and the integration respects it on each feed cycle. A product unpublished in your PIM will be delisted from OnBuy on the next sync.

How do we monitor if product, pricing or order data is stale on OnBuy?

The integration provides dashboards showing feed publish timestamps, order ingestion lag, stock sync frequency and API error rates. Alerts trigger if stock is older than your SLA (e.g., more than 2 hours old) or if orders are queued longer than your fulfillment target.

What happens to an order if OnBuy customer details (address, email) are wrong or incomplete?

Orders with incomplete or invalid addresses are flagged during validation and held in an exception queue. Your fulfillment or customer service team reviews the order, corrects the address if possible, or contacts the customer to confirm. Valid orders are released to fulfillment.

Can we run OnBuy as a test channel before going live with full inventory?

Yes. You can set a stock holdback or reserve a subset of inventory for OnBuy during pilot phase. Once you are confident in the integration and demand, the integration and OnBuy account are expanded to handle full inventory and volume.

How do we reconcile order data if the integration encounters an error during ingestion?

Failed orders are logged with full error detail and queued for replay. Your integration team investigates the error (e.g., bad address, invalid payment method) and either corrects the order data and replays it, or manually acknowledges the failure in OnBuy. Reconciliation reports are available to confirm all orders were processed.

What is the fallback behaviour if our ERP pricing system goes offline?

If pricing is unreachable, the integration halts new price publishes to OnBuy to prevent stale pricing. Existing prices remain live on OnBuy. Once pricing is restored, a full refresh is published. This prevents a window where OnBuy prices are out of sync with your ERP.

Next step

Have a OnBuy integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →