Emag Integration

Manually re-entering products and re-typing stock or price changes in the eMAG seller panel does not scale once a catalog passes a few dozen SKUs, and it is the single biggest source of stale prices and overselling on a fast-moving marketplace. Feeding eMAG programmatically lets you push new offers, price changes, and stock levels from your own PIM or storefront the moment they change, rather than on whatever cadence someone remembers to log in and edit listings by hand. It also lets you reach three markets — Romania, Bulgaria, and Hungary — from the same underlying product data, since all three run on the same Marketplace API and Feed Import mechanics.

eMAG does not charge a signup fee, a monthly subscription, or a per-listing fee. Sellers pay a category-based commission only on completed sales, and eMAG's own seller documentation states the commission 'varies between 7 and 25%, depending on the category' the product is listed in — the exact rate for each category is set out in the seller's Marketplace contract. Commission is deducted automatically before payout, and sellers are paid twice monthly. Sellers who opt into Fulfilled by eMAG (FBE) pay additional storage fees based on how long inventory sits in an eMAG warehouse, plus a per-order processing fee that starts at 3.99 RON and scales with package size and weight.

eMAG supports two distinct integration paths, and Feedance is built around the API path because it gives the tightest control over validation and update timing:

1. Marketplace API (recommended for automation) — JSON payloads sent via authenticated POST requests to resource endpoints such as product_offer, category, and order (e.g. product_offer/save, product_offer/read, product_offer/count). Every response is standardized JSON containing an isError boolean and a messages array, and a single save call is capped at 50 entities (10-50 is the range eMAG recommends for reliable processing), with a hard ceiling of 4000 elements per call.
2. Feed Import (XML/CSV) — a single hosted file URL that eMAG's Feed Import module re-fetches on a schedule you configure in the seller panel. A feed file is capped at 100 MB, a maximum of 100,000 products, and a maximum of 150 categories per feed.

Both paths ultimately populate the same underlying product/offer records, so the choice comes down to how much real-time control you need over validation responses and error handling — which is why Feedance defaults to the JSON API.

1. Get your eMAG Marketplace seller account approved and generate API credentials from the seller panel.
2. In Feedance, add eMAG as a destination and enter those credentials so Feedance can authenticate against the Marketplace API.
3. Map your product catalog fields to the product_offer schema — name, part_number, brand, sale_price, vat_id, stock, EAN, images, and the category-specific characteristics eMAG requires for each category_id you sell into.
4. Set your min_sale_price / max_sale_price bounds so future price updates don't get silently rejected once the offer is live.
5. Let Feedance validate the mapped feed, batch it into eMAG's recommended 10-50 entities per save call, and push it — while automatically pacing requests to stay under eMAG's rate limit rather than firing everything at once.
6. Review the isError / messages responses Feedance surfaces back from each push so rejected offers (bad category-characteristic pairing, price out of band, invalid EAN, etc.) get flagged for a fix rather than silently disappearing.

eMAG's own guidance is explicit about pacing: the Marketplace API allows a maximum of 1 request every 3 seconds and 20 requests per minute per account, and eMAG recommends against scheduling calls at round, fixed clock times (for example starting a batch at 12:04:42 rather than 12:00:00) so that many sellers' jobs don't collide on the same second. Within that ceiling, price and stock are the fields worth updating most aggressively — ideally every time they change on your side, and at minimum several times a day — since a stale stock figure on a fast marketplace directly costs you orders you can't fulfill or your ranking against competing offers on the same product page. A full catalog re-sync (new products, updated descriptions, images, characteristics) is reasonable on a daily cadence for most sellers; if you're using Feed Import instead of the API, the file is only as fresh as the last time eMAG's Feed Import module re-fetched your hosted URL, so check the refresh interval you configured in the seller panel.

The most common rejections documented in eMAG's Marketplace API reference are:

• isError: true with a messages array — eMAG's standard failure envelope; every request must be checked for this rather than assumed successful just because it returned HTTP 200.
• Invalid price (validation status 11) — triggered when a sale_price update falls outside the min_sale_price/max_sale_price band set on the offer's first save.
• EAN/brand/documentation validation pending or rejected (statuses 1-8) — eMAG runs new offers through Marketplace, brand, EAN, and documentation validation stages before an offer is approved (status 9); a malformed barcode (must be 6-14 numeric characters in a recognized EAN/UPC/GTIN format) is a frequent cause of stalling at the EAN stage.
• Category/characteristic mismatch — sending a characteristics entry whose ID isn't valid for the offer's category_id causes that save to be rejected.
• Image errors — images over 6000x6000 px or 8 MB, or in a format other than JPG/JPEG/PNG, are rejected.
• HTTP 429 rate limit exceeded — returned once you exceed 1 request/3 seconds or 20 requests/minute, along with X-RateLimit-Limit-3second / X-RateLimit-Remaining-3second headers you can use to back off before hitting the ceiling again.

• If a product already exists in eMAG's catalog, attach your offer to it with part_number_key instead of submitting a brand-new product — this skips re-validation and gets your offer live faster.
• Set realistic min_sale_price/max_sale_price bounds up front; too narrow a band means routine repricing gets rejected later, and eMAG only lets you set these on the first save.
• Get the EAN right the first time — barcode validation is one of the slower approval stages, and a rejected EAN blocks the whole offer from going live, not just that field.
• Populate every category-mandatory characteristic, not just the minimum to pass validation — eMAG's on-site filters are built from these values, and incomplete characteristics quietly reduce how findable your offer is in category browsing.
• Batch product_offer/save calls in the 10-50 entity range eMAG recommends, and stagger your job's start time away from round clock minutes to avoid rate-limit collisions with other sellers' scheduled jobs.
• Treat every isError: true response as actionable, not cosmetic — eMAG's own documentation notes that some failed saves still get partially processed, which can leave a listing in an inconsistent state if the error is ignored.

Does eMAG use an XML feed or a JSON API?
Both exist. The Marketplace API is JSON over authenticated POST requests and is the path Feedance automates. eMAG also offers a separate Feed Import option that accepts a hosted XML or CSV file, capped at 100 MB, 100,000 products, and 150 categories.

Can one feed cover Romania, Bulgaria, and Hungary at once?
Each country runs its own Marketplace account and its own API/seller-panel instance (emag.ro, emag.bg, emag.hu), so you connect to each separately, though the schema and mechanics are the same across all three.

What happens if I exceed eMAG's API rate limit?
You get an HTTP 429 response with a rate-limit-exceeded message. eMAG's limit is 1 request every 3 seconds and 20 requests per minute per account.

Is there a cost to use the eMAG Marketplace API itself?
No — there's no separate fee for API access. eMAG's revenue comes from the category-based commission (roughly 7-25%) charged on completed sales, not on integration or listing activity.

How many products can I include in a single API save call?
Up to 50 entities per product_offer/save call, with 10-50 recommended for reliable processing, and an overall cap of 4000 elements per call.