Connecting WooCommerce to eMAG
What "connecting Woo to eMAG" actually means
You have a WooCommerce store and you want to sell on eMAG Romania without re-keying products or copying orders by hand. Two things flow in opposite directions. Catalog, price, and stock go out from your store of record to eMAG. Orders come back into Woo — or, if you run an ERP behind Woo, into the ERP as a Sales Order. MEGZO sits between the two as a config-driven sync layer. Whichever system holds your master record keeps it; eMAG becomes a projection of that record, not a second place where your data lives.
That is the whole design decision. A hub like BaseLinker keeps the working copy of your catalog and orders inside its own panel, and over time that panel becomes where the data really lives. MEGZO maps fields across the boundary and leaves the master record where it already is.
Publishing the catalog: the eMAG rules a Woo seller hits first
WooCommerce thinks in gross. A product price in Woo is what the customer pays, VAT included. eMAG does not work that way, and this is where most first publishes fail.
- Price is ex-VAT. The sale price you send to eMAG excludes VAT; eMAG applies the rate and shows the gross price to the buyer. Send your Woo gross price raw and the listing reads that number plus VAT on the page. MEGZO de-VATs the source price as an explicit, previewable transform rather than a buried rule. More on the math in the ex-VAT pricing guide.
- min and max sale price are required. Every offer must carry a minimum and a maximum sale price, both ex-VAT. These are not optional — a publish is rejected without them, and rejected again if the band doesn't bracket your sale price. Woo has no native field for this, so the mapping has to supply it from a rule you set.
The mapping is per-field and per-direction, so the VAT math and the guard band are configuration you control and preview against a real product — not a black box you discover is wrong after a few hundred listings go out mispriced.
Stock sync without overselling
The classic multichannel failure is selling the last unit twice because Woo and eMAG raced. MEGZO publishes channel stock as max(0, available − buffer), where the buffer is configurable — the live reference seller runs a buffer of 2 — and reconciles continuously rather than trusting one push to stay accurate. You hold back a small cushion so a sale that lands on one side has slack before it shows on the other. The oversell guide covers how to tune it.
Pulling eMAG orders back — exactly once
An eMAG order has to become exactly one order on your side. Not zero, not two. MEGZO enforces that with a unique order link, a per-order lock, and a duplicate pre-check before it writes, so a retry, a replay, or a poller that runs twice never doubles anything. This is the part you cannot afford to get loose: a duplicated order means a second pick, pack, and ship.
Cadence is a 5-minute pull heartbeat plus webhook wake-ups where the channel supports them, so time-sensitive events don't wait the full interval. Two eMAG specifics worth knowing: awb/save mints the AWB and auto-finalises the order in the same call, so generating the label is the act that closes it out — there's no separate finalise step to forget. And eMAG keeps a 48-hour window in which an order's status can be reversed, which is why a daily reconciliation sweep matters as much as the live pull.
Invoices: the boundary, stated plainly
MEGZO can attach an invoice to the eMAG order, but read this carefully. It attaches an already-produced PDF — for example a file already generated in your ERP. MEGZO never generates a fiscal or legal invoice, and never creates or submits e-Factura to ANAF. Your ERP and ANAF own fiscal invoicing; MEGZO fetches the finished document and hands it to the channel. If your accounting depends on something producing the invoice, that responsibility stays exactly where it already is.
Woo alone, or Woo with an ERP behind it
If WooCommerce is your only system, it is the source of truth and orders land back in Woo. If you run an ERP behind the store, the same engine pours eMAG orders into the ERP as Sales Orders instead — the order flow is identical regardless of which back office sits at the end of it. That's the platform payoff: adding eMAG is a connector instance plus a few flow rows, not a rebuild. The Acumatica + eMAG version of this exact setup runs in production today for an anonymous Romanian eMAG seller.
Where to go next
If you're also weighing other marketplaces, note that eMAG's quirks aren't universal — Trendyol, for instance, prices in RON and demands a registered User-Agent header. Each channel has its own rules; the engine and your source of truth don't change. See all integrations, browse the other guides, or get started and we'll scope the eMAG cutover with you.