تكامل eMAG Odoo: ربط أكبر سوق في رومانيا بنظام تخطيط موارد المؤسسات (ERP) الخاص بك (الطلبات، المخزون، e-Factura)

An eMAG Odoo integration connects your eMAG Marketplace seller account to Odoo ERP through the eMAG Marketplace API, so that product offers, stock levels, prices, orders, AWB shipping labels, returns, and invoices flow automatically between the two systems. For most sellers, the right approach is a connector module installed inside Odoo that polls and pushes data on a schedule — orders pull into Odoo every few minutes, stock and price changes push back to eMAG, and Romanian e-Factura invoices are generated and submitted from Odoo's accounting layer. A working integration eliminates double data entry, prevents overselling, and keeps you compliant with Romania's mandatory e-invoicing rules.

eMAG is the largest online marketplace in Romania, with sister marketplaces in Bulgaria (emag.bg) and Hungary (emag.hu). If you sell physical products in Central and Eastern Europe, eMAG is very likely your highest-volume channel — and the one where manual order handling breaks down first. This guide covers what the eMAG Marketplace API can do, how each sync flow should work in Odoo, the e-Factura compliance angle that makes Romania different from almost every other marketplace market, and how to decide between an off-the-shelf connector and a custom build.

Key Takeaways

• The eMAG Marketplace API covers product offers, orders, AWB generation, returns (RMA), categories, and invoice attachment — enough for full ERP automation
• Orders should pull from eMAG into Odoo every 5–10 minutes; stock and price should push from Odoo to eMAG on change or on a 15–30 minute schedule
• Romania's RO e-Factura system makes invoicing the hardest part of the integration: B2B and B2C invoices must be submitted to ANAF in UBL-based XML, not just printed as PDFs
• eMAG order statuses (new, in progress, prepared, finalized, returned, canceled) must map one-to-one to Odoo sale order and delivery states — partial mappings cause stuck orders
• Fulfilment by eMAG (FBE) inventory must be modeled as a separate Odoo warehouse or location, never mixed with your own stock
• A connector module deploys in days and costs a fraction of a custom build; custom integration only makes sense for unusual catalog or pricing logic
• Odoo 17, 18, and 19 all support this integration pattern, but e-Factura localization is significantly more mature in Odoo 17+
• Always test against a small product subset first — eMAG validates offers strictly, and bulk failures are painful to diagnose

---

Why eMAG Sellers Outgrow Manual Operations

A seller doing 10 eMAG orders a day can survive on the seller portal alone. At 50–100 orders a day, the cracks appear in a predictable order:

1. Stock drift — you sell the last unit on your own webshop and eMAG still shows it available. The eMAG order arrives, you cannot fulfil it, and your seller performance score takes the hit. eMAG penalizes cancellation rates aggressively, and a degraded score directly suppresses your offers in search results.
2. Invoice backlog — every eMAG order needs a fiscal invoice, and since Romania's e-Factura mandate, that invoice must also be submitted electronically to ANAF (the Romanian tax authority). Doing this manually for hundreds of orders is not a clerical chore anymore; it is a compliance risk.
3. Shipping label chaos — eMAG's courier integration generates AWBs (air waybills) through its own platform. Without integration, your warehouse team works from two screens: Odoo for picking, the eMAG portal for labels.
4. Price update lag — eMAG is intensely price-competitive. Sellers who reprice weekly lose the buy-button to sellers who reprice hourly. Manual repricing through the portal cannot keep up.

Each of these problems maps to a specific API-driven sync flow, which is what the rest of this guide covers.

What the eMAG Marketplace API Covers

The eMAG Marketplace API is a REST-style API available to approved marketplace sellers. Authentication uses your seller account credentials, and each of the three country platforms (Romania, Bulgaria, Hungary) is a separate marketplace with its own endpoint and seller account. The functional areas relevant to an ERP integration:

Two practical realities to plan around:

• Strict offer validation. eMAG validates every offer against the category's required characteristics. An offer missing a mandatory attribute is rejected, and the error messages require some interpretation. Budget time for an initial catalog-mapping phase where you align Odoo product attributes to eMAG category characteristics.
• Rate limits and batching. The API enforces request limits and supports batch payloads (multiple offers per call). A well-built connector batches stock and price updates instead of firing one request per product — this matters once your catalog passes a few hundred SKUs.

The Five Core Sync Flows

1. Offer and Catalog Sync (Odoo → eMAG)

Products are mastered in Odoo and published to eMAG as offers. The connector maps:

A useful pattern: keep a per-product "publish to eMAG" flag and a per-product price override field in Odoo. Marketplace pricing usually differs from webshop pricing (commission, competitive pressure), and burying that logic in pricelists per sales channel keeps it auditable.

2. Stock Sync (Odoo → eMAG)

This is the flow that prevents overselling. Two designs work:

• Event-driven — every stock move in Odoo that touches a published product queues an offer update. Near-real-time, but requires queueing and debouncing so a 500-line inventory adjustment does not fire 500 API calls.
• Scheduled batch — a cron job every 15–30 minutes pushes the current available quantity for all published products in batched calls. Simpler, very robust, and fast enough for most sellers.

Whichever you choose, push available quantity (on hand minus reserved), not on-hand quantity. Odoo's forecasted or free-to-use quantity at the designated warehouse is the right source. Sellers who push raw on-hand stock oversell exactly when it hurts most — during demand spikes when many orders reserve stock simultaneously.

3. Order Sync (eMAG → Odoo)

The connector polls for new orders every 5–10 minutes, then for each order:

1. Creates or matches the customer as an Odoo contact (eMAG orders carry buyer name, shipping address, phone; for B2B orders, company and tax ID)
2. Creates a sale order with the marketplace as the sales channel, lines matched by SKU
3. Confirms the sale order, reserving stock and creating the delivery order
4. Acknowledges the order on eMAG, moving it from "new" to "in progress"

Status mapping must be complete in both directions:

The most common integration bug we see in audits is a missing transition — for example, orders that reach "prepared" on eMAG but whose Odoo delivery was validated outside the normal flow, leaving the marketplace status stale. Build the status push into Odoo's delivery validation itself, not into a separate manual action.

4. AWB and Shipping Sync (Odoo → eMAG)

When the Odoo delivery order is validated (or at picking completion, depending on your workflow), the connector calls the AWB endpoint with parcel count and weight, receives the waybill number and label PDF, and attaches the label to the Odoo delivery for printing. The tracking number is stored on the delivery and pushed to the order so the customer gets tracking visibility inside eMAG.

If you ship FBE (Fulfilment by eMAG), this flow is replaced by inventory transfers: you model the eMAG fulfilment center as a separate Odoo warehouse, move stock to it with inter-warehouse transfers, and let eMAG handle outbound logistics. Never co-mingle FBE stock with your own warehouse quantities in Odoo — your stock sync for seller-fulfilled offers must exclude FBE locations, and FBE replenishment needs its own reordering logic.

5. Returns Sync (eMAG → Odoo)

Return requests (RMAs) pull into Odoo as return pickings linked to the original delivery, with the eMAG return reason captured for reporting. On receipt and approval, Odoo issues the credit note — which, in Romania, is itself an e-Factura document that must be submitted to ANAF, not just emailed to the customer.

The Romanian e-Factura Angle

This is what makes an eMAG integration materially different from, say, a Noon integration in the Middle East: the invoicing leg is regulated end-to-end.

Romania's RO e-Factura system requires invoices to be submitted electronically to ANAF through the SPV (Spațiul Privat Virtual) platform in a structured XML format based on the European e-invoicing standard (UBL with the Romanian CIUS profile). The mandate rolled out in phases — first B2G, then B2B for established taxpayers, and subsequently B2C — so as a practical matter, an eMAG seller in Romania should assume every order's invoice needs an e-Factura submission, whether the buyer is a consumer or a company.

What this means for the integration architecture:

Practical guidance:

• Use Odoo 17 or newer if e-Factura matters to you. The Romanian e-invoicing localization is significantly more complete from Odoo 17 onward. On older versions you will be patching community localization modules or building the ANAF submission yourself.
• Sequence matters. The clean flow is: delivery validated → invoice created and posted in Odoo → e-Factura XML generated and submitted to ANAF → PDF attached to the eMAG order → order finalized. Finalizing the eMAG order before the invoice exists creates a backlog of compliance debt that is tedious to unwind.
• B2B orders need the buyer's tax ID. eMAG provides company details on B2B orders; your connector must map the CUI (Romanian tax identifier) onto the Odoo partner so the e-Factura document validates.
• Where your situation is unusual (VAT grouping, special schemes, cross-border supplies from Bulgaria or Hungary into Romania), confirm the document flow with your Romanian accountant — the integration should encode their answer, not guess at it.

Multi-Country Setup: Romania, Bulgaria, Hungary

eMAG operates three country platforms, and sellers approved on more than one should treat each as a separate sales channel in Odoo:

• Separate API connections per country, since each platform has its own seller account and endpoint
• Separate pricelists in RON, BGN, and HUF — do not auto-convert from a single base price; marketplace price points are set per market
• Country-specific VAT — Romania, Bulgaria, and Hungary have different standard VAT rates, and Hungary in particular has its own real-time invoice-reporting regime (NAV Online Számla) that parallels Romania's e-Factura
• One warehouse, channel-aware allocation if you ship all three markets from a single Romanian warehouse — your stock sync should support reserving a buffer per channel so one marketplace cannot drain stock promised to another

Connector Module vs. Custom Build

Our recommendation is blunt: start with a connector module unless you have a specific, written-down requirement a connector cannot meet. The eMAG API's mechanics — authentication, batching, offer validation quirks, status choreography — are undifferentiated plumbing. Your money is better spent on catalog quality, pricing strategy, and the e-Factura accounting flow. Custom work, when needed, is usually a thin extension layered on top of a connector (a custom repricing rule, a bundle-explosion step) rather than a ground-up build.

ECOSIRE builds and maintains Odoo marketplace connectors as part of our Odoo integration services, and our published modules are available per Odoo version in the Odoo apps marketplace.

Per-Odoo-Version Availability

Each Odoo major version is a separately licensed module build — verify your connector matches your exact Odoo version (17.0, 18.0, or 19.0) before purchase, and re-license when you upgrade.

Implementation Roadmap

A realistic sequence for a mid-size seller (500–5,000 SKUs, 50–300 orders/day):

1. Week 1 — Foundations. API credentials per marketplace, connector installation in a staging database, category and characteristic mapping for your top categories, VAT rate mapping.
2. Week 2 — Catalog pilot. Publish 20–50 offers from Odoo, fix validation errors, verify price and stock round-trips.
3. Week 3 — Order flow. Run end-to-end on live orders for the pilot subset: import, confirm, pick, AWB, invoice, e-Factura submission, finalize. Verify every status transition on both sides.
4. Week 4 — Scale and cut over. Publish the full catalog in batches, enable scheduled stock/price sync for everything, switch the warehouse team fully to Odoo-driven picking, and decommission manual portal workflows.
5. Ongoing. Monitor a daily exception report: rejected offers, orders stuck in a status for more than N hours, e-Factura rejections. The integration is healthy when this report is empty.

Common Pitfalls

• Pushing on-hand instead of available stock — the single most common cause of marketplace overselling.
• Importing orders without confirming them — draft sale orders do not reserve stock, so the anti-overselling benefit silently disappears.
• Treating e-Factura as a PDF problem — attaching a PDF to the eMAG order satisfies eMAG, but only the XML submission to ANAF satisfies the law. You need both, in the right order.
• One-way status sync — cancellations initiated by the buyer on eMAG must cancel the Odoo order and release stock; many home-grown scripts only sync the happy path.
• Ignoring the seller performance feedback loop — fast acknowledgment, accurate handling times, and low cancellations improve your offer ranking. The integration is not just back-office hygiene; it is a sales lever.

Frequently Asked Questions

Does eMAG have an official Odoo connector?

eMAG publishes the Marketplace API and approves sellers for API access, but it does not ship an official Odoo module. Integrations are built by Odoo partners and module vendors against the documented API. When evaluating a connector, check that it covers all five flows — offers, stock/price, orders, AWB, and returns — plus invoice attachment, and that it is built for your exact Odoo major version.

How often should stock and prices sync between Odoo and eMAG?

Orders should be pulled every 5–10 minutes. Stock updates should push either event-driven (on every relevant stock move, debounced) or on a 15–30 minute batch schedule — faster than that adds API load without meaningfully reducing oversell risk for most sellers. Price updates can run on the same batch cycle, or more frequently if you operate an automated repricing strategy in a competitive category.

Do I need e-Factura for eMAG consumer orders, or only B2B?

Plan for both. Romania's RO e-Factura mandate was extended beyond B2G and B2B to cover B2C invoicing as well, so the safe operating assumption for a Romanian eMAG seller is that every invoice — consumer or company — goes through the ANAF submission pipeline. Confirm the current scope and any threshold rules with your Romanian accountant, and make sure your Odoo localization is configured to submit, track, and resubmit rejected documents.

Can one Odoo database handle eMAG Romania, Bulgaria, and Hungary together?

Yes, and it is the recommended setup. Configure one API connection per country platform, separate pricelists in RON, BGN, and HUF, country-correct VAT and invoicing rules per market, and channel-tagged sale orders so reporting separates the three marketplaces. If you fulfil all three from one warehouse, add per-channel stock buffers so a spike on one marketplace cannot oversell the others.

How does Fulfilment by eMAG (FBE) change the integration?

FBE stock physically sits in eMAG's fulfilment centers, so you model it as a dedicated Odoo warehouse. Replenishment becomes an inter-warehouse transfer instead of a customer shipment, eMAG handles outbound delivery (no AWB flow on your side for FBE orders), and your stock sync for seller-fulfilled offers must exclude FBE locations. You also need separate reordering logic to keep FBE stocked — treat it like replenishing a remote branch warehouse.

Connector module or custom integration — how do I decide?

Start from your requirements list. If everything on it is standard marketplace mechanics (orders, stock, prices, labels, returns, invoices), a connector module gets you live in days at a fraction of the cost and the vendor absorbs eMAG API changes. Choose custom work only for genuinely bespoke logic — and even then, build it as an extension on top of a connector rather than reimplementing the plumbing. Our Odoo integration team can scope both options against your requirements in a single workshop.