The Entire Iherb Supplements Catalog, Captured End-to-End in 3 Days
Scraping supplement products from iHerb.com with full details, including descriptions and packaging variations.
Learn More
We run the crawlers and hand over data. Output is CSV, JSON, XLSX or a REST endpoint your systems poll, with the schema agreed before the first run and kept stable afterwards. Delivery goes to S3, Google Cloud Storage, SFTP, a webhook or plain email, whichever fits the pipeline already in place.
Scope is defined by category, brand, vendor storefront, search query or a list of PNKs you supply. Frequency runs from a one-off catalogue export to daily or intraday price and stock refreshes on a watchlist. Every run can emit a full snapshot, or a changed-only feed carrying just the offers whose price, seller or availability moved since the previous run, which keeps volumes manageable on large categories.
eMAG product pages are server rendered. Price, stock state, seller and the competing offers all sit in an EM.* JavaScript object inside the HTML, so no headless browser is needed for the commercial fields. We map them to a flat schema using the platform's own naming.
A single pull from eMAG.hu is a catalogue. The commercially useful signal appears only when the same PNK is fetched again on a schedule.
Because a product URL stays live after its offer sells out, change detection has to key on offer id rather than on the page. Sellers appear and vanish on a PNK, the buy button changes hands, offers_count moves and multiple_min_price shifts while the product title stays identical. eMAG publishes separate offers-available, offers-unavailable and offers-latest sitemap groups, which lets a repeated crawl classify what happened: a new listing, a delisting, or an offer that went out of stock and came back.
Price history is the second signal. lowest_price_30_days moves on its own schedule, so a discount percentage that looks steady can be measured against a falling reference. Recording the current price and that reference on every run gives a defensible view of what an offer really cost before Fekete Péntek and after it.
Stock is the third. The availability code, the Raktáron label and days_estimation change faster than price, and restock behaviour per vendor is visible only as a series.
Feedback is the fourth. Only the first ten reviews are server rendered inside the Product JSON-LD review array, even on a product showing far more vélemény (reviews); the remainder and the answers to buyer questions come from the sapi.emag.hu feedback microservice, so a periodic pull against a stored count keeps the corpus current without refetching everything.
eMAG.hu is the Hungarian storefront of the eMAG marketplace, operated by Dante International Kft. after the Extreme Digital and edigital.hu catalogues were folded into it. As a data source it is unusually well structured. Every product sits at a URL of the form /slug/pd/PNK/, where the part number key is a nine-character uppercase alphanumeric code such as EL272BBBM. In a 5,000-URL sample taken from eMAG's own offers-available sitemap, every code was exactly nine characters. The same key is reused across borders: product pages emit hreflang alternates pointing at emag.ro and emag.bg with an identical PNK, so a single identifier joins the Hungarian, Romanian and Bulgarian catalogues.
Page type is encoded in the suffix. /d is a department, /sd a sub-department, /c a category, /pd/PNK/ a product, and /sef_name/vendorId/v a seller storefront - eMAG itself is /emag/1/v. Brands sit under /brands/brand/, search under /search/query/pN. Listings render 60 products per page and stop at page 100, so a category such as /ferfi-polok/c (men's t-shirts) that reported 92,216 termék (products) next to its H1 when we last crawled it cannot be walked by paging alone: /ferfi-polok/p101/c returns an empty grid.
The storefront is Hungarian-language and HUF-only. There is no EUR view - html lang is hu, EM.locale is hu, and prices are gross forint written with a dot thousands separator and a Ft suffix. A product URL stays live after its offer sells out, so churn happens underneath the URL, at offer level.
Get a QuoteDevelopers
Customers worldwide
Pages extracted
Hours saved for our clients
€199 / one-time
setup fee - included
€169 / mo
setup fee €499
€229 / mo
setup fee €499
€349 / mo
setup fee €499
€549 / mo
setup fee €799
Sellers already on eMAG Marketplace use this to see the part of the market their own account cannot show them. product_offer/read reports number_of_offers, buy_button_rank and best_offer_sale_price, but only for products the account already lists, and nothing about categories it does not sell into. Collecting the public storefront closes that gap: every rival offer on a PNK, in Ft, with the vendor behind it.
Brands and distributors use it for price policy. Because eMAG discounts against the lowest selling price in the previous 30 days, a card showing a large percentage off can still sit above a brand's floor, and only lowest_price_30_days explains the number being advertised. Tracked per PNK, that makes a reseller pricing conversation concrete.
Retailers outside the marketplace treat it as a market reference. The state filters /raktaron/c, /akciok/c and /ujracsomagolt/c isolate in-stock items, promotions and resealed goods, so a category can be benchmarked on what is actually buyable rather than on catalogue entries. Around Fekete Péntek, the Hungarian Black Friday, the same crawl becomes a promotion log.
Cross-border teams use the shared PNK to compare the Hungarian assortment with emag.ro and emag.bg and find products listed in one country but missing in another.
Scraping supplement products from iHerb.com with full details, including descriptions and packaging variations.
Learn More
Daily scraping of lowest prices for 150K products on Allegro.pl to support marketplace pricing and margin optimization.
Learn More
Regular monitoring of Ralph Lauren clothing, footwear, and accessories sold across Amazon subdomains: AE, DE, ES, FR, IT, NL, PL, UK.
Learn MoreLearn how to use web scraping to solve data problems for your organization
If you sell online, run a marketplace, or advise e-commerce clients, you already know why eBay matters: it’s one of the few places where big retailers compete side by side with thousands of small merchants and private sellers.
E-commerce teams do not just need “some” competitor data anymore. They need a continuous stream of real prices, discounts, stock levels, reviews, and seller behavior from the platforms that actually shape their markets.
Amazon provides valuable information gathered in one place: products, reviews, ratings, exclusive offers, news, etc. So scraping data from Amazon will help solve the problems of the time-consuming process of extracting data from e-commerce.
ScrapeIt is a managed service. You describe the eMAG.hu scope and the fields you need; we build the crawler, run it on your schedule, watch it and repair it when the markup or the URL grammar shifts. Nothing is installed on your side and no proxy account is yours to babysit. Marketplace pages change often, and the point of this arrangement is that someone else absorbs that maintenance while the schema you load stays the same.
eMAG.hu sits behind AWS WAF. When it treats traffic as unusual the site answers with HTTP 511 and an eMAG Captcha interstitial reading "Szokatlanul nagy forgalmat észleltünk" (we have detected unusually heavy traffic), loads captcha-sdk.awswaf.com and sets an aws-waf-token cookie across .emag.hu, .www.emag.hu, .sapi.emag.hu and .m.emag.hu. The block is network level: it applies to every path, including /robots.txt and the sitemap files, and a fresh cookie jar does not clear it. We do not defeat that protection and we do not solve captchas. We work within it by keeping request rates modest, spreading collection across time, and sizing the schedule to the volume you actually need. If a requested refresh rate is not realistic for the scope you want, we say so before the project starts rather than after.
We read only pages eMAG publishes to anonymous visitors: product pages, category and filter listings, vendor storefronts and public reviews. No account, no login, no checkout, no personal data. Reviewer display names are dropped by default unless you ask for them and have a reason to hold them. Whether a particular use is permitted still depends on your jurisdiction, your purpose and eMAG's terms of use, so treat this as an engineering description and not as legal advice, and confirm the intended use with your own counsel. We will narrow scope, fields or frequency to keep a project inside whatever boundary you set.
Yes. Product pages carry EM.multiple_offers inline - the whole array of competing offers with offer id, price and vendor - next to EM.offers_count and EM.multiple_min_price. One HTML response is enough to reconstruct the full competitor set for a part number key, including the seller currently holding the buy button. This is the usual reason teams come to us: the official eMAG Marketplace API at marketplace-api.emag.hu/api-3 is seller-scoped, so buy_button_rank and best_offer_sale_price arrive only for products your own account already lists, and rival catalogues stay invisible.
Not by paging. Listings show 60 items per page and hard-stop at page 100, so /category/p101/c returns an empty grid even when the heading reports far more termék. We split the category using eMAG's own URL grammar instead: price,between-min-and-max ranges, /brand/ and /vendor/ segments, filter-f facet and value pairs, rating,star-5, and the state filters raktaron, akciok, ujdonsagok (new arrivals), ujracsomagolt and preorder, until every slice fits under the cap. The result is cross-checked against the sitemap indexes published in robots.txt, where, on a recent read, offers-available alone indexed 468 child sitemaps and categories-0.xml listed 1,761 category URLs, while vendors-0.xml and brands-0.xml are capped at 10,000 URLs each.
The displayed price is gross forint, printed with a dot thousands separator and a Ft suffix, for example 86.790 Ft, and we deliver it as a clean number with the currency in its own column. The embedded offer object also exposes a net value, so the row carries both the VAT-inclusive figure and the ex-VAT figure behind Hungary's 27% rate. For promotions we store current price, kezdeti ár, discount percent and lowest_price_30_days on every run, which is the reference the Omnibus rule anchors a reduction to, so a Fekete Péntek claim can be checked against the price the offer actually sold at beforehand. Raising frequency for the promotional weeks and dropping back afterwards is a normal arrangement.
Step 1 - Make a Request
You share your needs, expectations, and desired timeframe. We’ll suggest the best solution based on your request and budget.
Step 2 - Configuring Custom Web Crawlers
Our specialists configure the crawlers and extract a sample dataset for your review before proceeding with the full-scale extraction.
Step 3 - Collect and Deliver
Once you approve the sample, we launch the project and start full data collection. We gather, filter, and structure the data for easy use, delivering it on time in your preferred format.
Step 4 - Maintain and Support
Our team manages ongoing processes, monitors website changes, and supports all data extraction cycles. We can also help integrate data into your systems or create dashboards to simplify analysis.
Scrapeit Sp. z o.o.
10/208 Legionowa str., 15-099, Bialystok, Poland
NIP: 5423457175
REGON: 523384582