eMAG Scraper - Products, Prices, Sellers & Stock
Under maintenancePricing
from $1.60 / 1,000 product records
Scrape eMAG products across Romania, Hungary, Bulgaria and Poland by keyword or URL. Extract product names, prices, discounts, sellers and stock availability. Optional enrichment adds descriptions, specifications and customer ratings.
How to start the scrape. 'search' runs store searches on the picked store. 'url' processes the store URLs you paste: a product URL is fetched as a single product, and a search URL is paged like a search, its own query, store and page deciding the scope. The filters below apply to every walk in both modes; a pasted product URL is the one exception and returns that single product in full.
One or more things to search the store for, for example 'telefon', 'masina de spalat', 'laptop'. Each term is scraped independently. Search mode only: in URL mode the scope is read out of each pasted URL instead. Leave this empty and the run browses the current offers with only the filters applied.
[ "telefon"]Paste product URLs (ending in /pd/XXXXXXX/) or search URLs (containing /search/). A search URL may carry /p3 to start the walk further in and /sort-priceasc to order it. A product URL ignores paging and returns that one product in full. Category pages (.../c) are not supported: the store answers them with a captcha.
[ "https://www.emag.ro/search/telefon", "https://www.emag.ro/telefon-mobil-apple-iphone-17-pro-256gb-5g-silver-mg8g4zd-a/pd/DN99FV3BM/", "https://www.emag.ro/search/telefon/sort-priceasc/p2", "https://www.emag.hu/search/telefon"]Applies in BOTH search mode and URL mode. In search mode it picks which country store to search: Romania, Hungary, Bulgaria or Poland, with rows priced in that store's currency. In URL mode each pasted URL carries its own store, so this is only the fallback for search walks.
The store's own server-side ordering, sent with every page of every search walk. This orders the walk itself (and therefore which rows a capped run keeps), not just the output. Applies in BOTH search mode and URL mode search walks; a pasted search URL with its own /sort- value keeps that instead.
Only keep rows whose selling price is at least this much, in the store's currency. The store has no parameter for this, so it is applied to the rows this run reads. Applies in BOTH search mode and URL mode.
Only keep rows whose selling price is at most this much, in the store's currency. The store has no parameter for this, so it is applied to the rows this run reads. Applies in BOTH search mode and URL mode.
Only keep rows whose selling price is below the original price, that is rows with a discount. The store has no parameter for this, so it is applied to the rows this run reads. Applies in BOTH search mode and URL mode.
Fetch each item's product page for the description, brand, specifications, image gallery, seller rating, stock state and rating summary. Slower, and billed one unit per enriched record plus one unit per started block of 10 delivered reviews. Leave off for a fast crawl: identity, prices, discount and category are included either way.
The single cap on this run: stop after collecting this many records across all search terms and URLs. Set 0 for unlimited.
Safety bound on how many result pages to walk per search term or URL. Leave empty (0) for no page limit: the run then stops at Max items, not here. Does not impose a separate cap below Max items.
How many reviews to keep per product record, with Fetch product details on. Reviews are read from the product page already fetched for the details, so the cap adds no page read; every started block of 10 reviews bills one extra details surcharge unit. Set 0 to skip reviews entirely.
Leave the default for the most reliable run. Residential is recommended for the most reliable results: the storefront answers residential exits most consistently, and datacenter exits are refused more often. Change it only if a run reports that it could not read any results.
{ "useApifyProxy": true, "apifyProxyGroups": [ "RESIDENTIAL" ]}Paste a previous run ID or dataset ID to continue a large crawl without returning or charging for records already collected there. Use this after an interrupted or capped run. For recurring monitoring of the same search, use Incremental mode below instead.
Turn this on for daily or weekly recurring monitoring of the same search, for example a price watch. The first run returns everything matching as NEW. Later runs normally return only NEW, UPDATED and REAPPEARED records. Price moves, stock changes and new ratings ARE reported as UPDATED: on a store they are the signal, not noise. Image URLs never mark a row UPDATED on their own. Turn on Emit unchanged or Emit expired only when you also want those rows returned (and billed). State is kept separately per search, URL and filter setup; use State key to name or deliberately share a monitoring campaign. To continue one specific interrupted run instead, use Resume from a previous run above.
Optional. Name this monitoring campaign to keep its state stable, or to deliberately share state across differently configured runs. Leave empty to let the actor derive a key automatically from the search terms, URLs and filters, so two different searches never mix state.
Off by default. Turn on to also return records that have not changed since the last run, marked UNCHANGED. This returns, and bills, extra rows you already have, so leave it off unless you specifically want a full snapshot every run.
Off by default. Turn on to also return records that were present in a previous run but are no longer found, marked EXPIRED. Only produced once a run has fully scanned the tracked search: not when Max items capped it, not when Resume was used, and not when the run was refused. This returns, and bills, extra synthetic rows, so leave it off unless you need expiry tracking.
Incremental mode only. Extra field names to keep out of the change fingerprint, on top of the built-in image URL ignore list. Use this when a field moves on every run without the product changing. Price, stock and rating fields are never ignored: on a store they are the signal.
Optionally send results into the apps you already use, via Model Context Protocol (MCP) connectors. Authorize one under Apify, Settings, API and Integrations, then select it here. Notion gets a page per record; other connectors get a best-effort write or digest. Each connector receives a condensed summary per record, not the full record; the complete record always stays in the dataset. Leave empty to skip; this never changes the dataset output. Supported: Notion (https://mcp.notion.com/mcp), Linear (https://mcp.linear.app/sse), Airtable (https://mcp.airtable.com/mcp), Apify (https://mcp.apify.com).
URL or id of the Notion page under which record pages are created. Required to enable the Notion export; ignored by other connectors.