Most ERP-to-marketplace integrations don't fail on launch day. They fail three weeks later, on a Saturday, when one SKU goes negative and Amazon keeps selling it. By then nobody remembers who configured what.
An ERP (the system where your business actually lives: stock, orders, invoices, costs) and a marketplace speak different languages. The ERP thinks in internal references and warehouses. Amazon thinks in ASINs, seller SKUs and fulfilment centres you don't control. Connecting them isn't "switching the connector on". It's deciding who owns each piece of data.
What travels, and in which direction
Before you touch anything, map the flows. On paper. Most disasters come from not being clear about the source of truth (the system that decides the correct value when two systems disagree) for each field.
Outbound, from ERP to marketplace, you normally send:
- Catalogue: titles, descriptions, attributes, EAN, dimensions and weight.
- Prices: selling price and, if you use it, the was-price or promotional price.
- Available stock: the quantity you're willing to sell on that channel.
- Dispatch confirmations: tracking number and carrier.
Inbound, from marketplace to ERP, you receive:
- Orders: lines, quantities, address, amounts and fees.
- Status changes: cancellations, held orders, corrected addresses.
- Returns and refunds, with the reason, which is gold for quality work.
- Fulfilment stock movements: if you use FBA, your goods sit in Amazon warehouses and the ERP needs to know.
Practical rule: the ERP owns catalogue and price. The marketplace owns the order. The ERP owns stock, but only the stock you've decided to hand to that channel.
The flow table you should have written down
This table is the single most useful document in the whole project. If your vendor can't fill it in with you, they're not ready to integrate you.
| Data | Direction | Sensible frequency | What happens if it fails |
|---|---|---|---|
| New product listing | ERP to marketplace | On demand or daily | It doesn't go live; no impact on current sales |
| Listing changes | ERP to marketplace | Daily | The listing goes stale; low risk |
| Price | ERP to marketplace | Every 1-4 hours | You sell at the old price; margin at risk |
| Stock | ERP to marketplace | Every 15-60 min | Overselling, cancellations and damaged account metrics |
| Orders | Marketplace to ERP | Every 5-15 min | Orders sit unpicked; late dispatch risk |
| Dispatch confirmation | ERP to marketplace | Every 15-30 min | The marketplace records it as a late shipment |
| Returns | Marketplace to ERP | Hourly or daily | Phantom stock and refunds that don't reconcile |
| Settlements and fees | Marketplace to ERP | Fortnightly or monthly | Accounts out of line; you can't see your real margin |
Write the intervals down and keep them somewhere the team can check. When someone asks why the old price is still showing, the answer is in the table, not in one person's head.
Why stock is the point that hurts most
Selling something you don't have isn't just an annoyed customer. It's a seller-side cancellation, and the pre-fulfilment cancel rate (orders you kill, not the buyer) is one of the metrics Amazon watches when deciding whether your account is healthy. Check the exact thresholds in Seller Central because they move, but the logic doesn't: cancelling is expensive.
The underlying problem is timing. Minutes pass between reading stock in the ERP and the marketplace publishing it. In that gap you can sell through another channel. For normal-rotation products it doesn't matter. For a line with three units selling across four channels, it's an oversell waiting to happen.
What works in the accounts we manage:
- A safety buffer per SKU, not a global one. Three units, publish one. Four hundred units, publish 395. A flat 10% doesn't serve both cases.
- Channel-level stock allocation on critical lines: reserve a quantity for the marketplace and leave the rest alone.
- Automatic cut to zero when stock drops below a floor. Losing three sales beats taking a cancellation.
- Priority syncing for fast movers. Not every SKU needs the same rhythm.
Real time: why it isn't always the answer
"We want real-time sync" sounds great until you hit rate limiting. Marketplace APIs have call limits (how many requests you can make per minute before they start rejecting you), and if you burn them updating stock on SKUs that never move, you've got nothing left for what matters.
The approach that holds up combines three rhythms:
- Batch, for the bulk: full catalogue and prices, once or a few times a day.
- Event-driven, for the critical: when an order lands on any channel, update that specific SKU everywhere else.
- Full overnight reconciliation: a pass that compares everything and fixes the gaps.
That third one is the safety net that saves projects. Without it, small divergences pile up for months and one day you find the ERP and the marketplace disagree on forty SKUs and nobody noticed.
Middleware, direct integration or off-the-shelf connector
Three routes, and none of them is always right.
| Option | When it makes sense | Main risk |
|---|---|---|
| Off-the-shelf connector (the usual multichannel feed tools) | Standard catalogue, few channels, small team | You bend to their data model; odd cases don't fit |
| Middleware or integration platform | Several channels, your own rules, data needs transforming | Recurring cost and one more thing to maintain |
| Direct API integration | High volume, very specific logic, in-house tech team | You own every API change, and the marketplace won't wait |
Direct integration looks cheapest in year one. It stops being cheapest the day the marketplace retires an API version and nobody on your team remembers that endpoint existed. If you go that way, budget for maintenance, not just build.
SKUs that don't match: the mapping table
This is the most common silent failure. Your ERP calls a product CAM-AZ-42. The marketplace has it as SHIRT-BLUE-42. Your own shop uses shirt_blue_42. Everything works until someone creates a new variant and the mapping breaks on one side.
You need a mapping table (the record linking your internal reference to each channel's) that meets three conditions:
- It lives in one place with a change history, not in a spreadsheet on somebody's desktop.
- It has an owner. One named person responsible for adds and removals.
- It's validated before every bulk upload: if a reference has no match, the upload flags it instead of guessing.
And one decision that saves a lot of pain: the seller SKU you use on the marketplace should be the same code as in the ERP wherever you can manage it. Every translation you avoid is one failure fewer.
Errors, retries and alerts someone actually reads
An integration with no error handling is an integration that's already failing and you don't know yet.
- Retries with growing waits: if the API rejects a call, retry after 30 seconds, then two minutes, then ten. Don't hammer it.
- A failed queue: whatever doesn't land after retries goes to a visible list, not into the void.
- Separate temporary errors from data errors: a timeout is worth retrying; an invalid EAN never fixes itself, someone has to correct it.
- Threshold alerts: don't fire on every failure or people stop reading them within two days. Fire if more than X fail in an hour, or if no order has landed in Y minutes.
That last point matters more than it looks. "No orders have come in for three hours" catches half the real problems, and almost nobody has it set up.
How to test without wrecking live orders
- Use the marketplace sandbox for the basic flow. It won't reproduce everything, but it validates formats and permissions.
- Start with a subset of 20 or 30 low-risk SKUs. A real pilot beats a perfect sandbox.
- Read-only first: let the integration pull orders into the ERP for a week without pushing stock or prices. Compare by hand.
- Test the ugly cases: order cancelled before picking, partial return, product going out of stock mid-sync, an order with two lines of the same SKU, buyer-edited address.
- Have a kill switch. If something goes wrong at ten on a Friday night, someone has to be able to stop the price sync without ringing the developer.
What to ask your ERP vendor before signing
Specific questions. If they dodge one, note it:
- Is the connection native or through a third party, and who supports it when it breaks.
- Exactly which fields sync and in which direction. In writing.
- What frequency it supports per data type, and whether the plan caps operations.
- How it handles errors: whether there's a failure dashboard and automatic retries.
- Whether it supports multiple warehouses and per-channel stock reservation.
- Who updates the integration when the marketplace changes its API, and how fast.
- Whether you can export your mapping table and history the day you leave.
- Whether there's a test environment separate from production.
Number seven makes sales people uncomfortable and protects you most.
Where to start this week
- Draw the flow table with your real data: what travels, where, how often, and what happens when it fails. An hour of work that saves you weeks.
- Check your 20 best sellers and see whether ERP stock matches what's published on each channel today. If it doesn't, you've found your first problem.
- Set up a no-orders alert: if X hours pass with nothing coming in, get a message. It's the cheapest detection there is.
- Define safety buffers by rotation, not one flat percentage, starting with every SKU under five units.
- Write down who owns the mapping table, by name. If nobody owns it, chaos will.