You set the scope: a category id, a keyword list, a brand, or a set of productId values you already track. We build the crawler, run it on the cadence you pick, and hand back clean rows with the identifiers intact.
Output is CSV, JSON, XLSX or an API endpoint your systems call. We can push to S3, to Google Cloud Storage, or into a database you own. For price and offer work we keep dated snapshots instead of overwriting, so a change in price, in stock or in the merchant on display reads as a series.
Maintenance is included. When Coupang changes its markup we fix the crawler, and that is part of the service rather than a change request.
A Coupang row is only useful when it is anchored to the right identifier, so we keep all three and label every value with the level it belongs to.
Review text, the full option matrix and the seller list can be added on top, depending on what the job actually needs.
The common failure is collapsing three identifiers into one. A productId is a page. An itemId is a variant of that page. A vendorItemId is one merchant's offer on that variant, with its own price, its own shipping fee and its own stock, and a single productId can carry a whole matrix of them, keyed in the payload by a comma-joined pair of option value ids. Store only the productId and you average several merchants and every size variant into one meaningless number.
The canonical tag makes this worse rather than better. On a detail page it points at /vp/products/{productId} with itemId and vendorItemId stripped out. The JSON-LD sku is not the vendorItemId either: it is the productId and the itemId joined by a hyphen. Neither value is a safe primary key for an offer.
Coupang also merges and splits products, so a productId is not stable across months. Reviews pool across every merchant selling the same product, so a rating describes the page and not the merchant currently on display. And the arrival promise is Korean prose, not a date field: it names a weekday, a date and the shipping mode, seller delivery (판매자배송) rather than Rocket Delivery (로켓배송), and the structured shipping data alongside it is quoted for the Seoul region.
Coupang is the dominant online marketplace in South Korea. It sells stock it has bought outright, it runs fulfilment for third-party merchants, and it lists merchants who ship themselves. All three models land on the same detail page and in the same search results, which is the first thing a crawler has to untangle.
Every public product URL follows one grammar: /vp/products/{productId}, normally with itemId and vendorItemId carried in the query string. Coupang's own seller documentation describes productId as an ID that can be changed at any time by merging and unmerging, and calls vendorItemId the lowest-level identifier for products sold on Coupang, one that cannot be changed. Category listings sit at /np/categories/{categoryId}, and the same numeric category id drives the bestseller ranking at /np/best100/bestseller/{categoryId}.
The front end is a Next.js application that ships listing and detail data as a serialised JSON payload inside the HTML. That means a crawler reads Coupang's own field names rather than guessing at rendered text. Money arrives as an object of amount, rawAmount, currency and fractionDigits, and the currency is Korean won.
Get a Quote
Developers
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
Coupang publishes an Open API, but it is a vendor API. Calls are signed with HMAC and carry an X-Requested-By header holding your vendorId, and keys are issued through the WING seller portal. It manages the listings you already own. It will not read a competitor's price, a rival's stock position, or the catalogue at large.
So the market view lives on the public pages, and those pages move. The offer on display can change the moment another merchant undercuts it. The arrival promise is recomputed on every request. Stock flips, coupon prices expire, and a page that carried a Rocket badge last month may not carry one today. A single snapshot disagrees with the next one, which is exactly why this is a scheduled job rather than a one-off export.
Coupang states the criteria that decide which merchant is shown on a shared page: price competitiveness, shipping conditions, keeping stock available, and answering customer enquiries promptly. Three of those four are observable from outside, which is what makes offer-level history worth keeping rather than just the current price. Watching the same vendorItemId over weeks tells you when a rival cut price, when the badge changed, and when the page went out of stock.
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 web scraping agency. We build the crawlers, run them, watch them, and repair them when a site changes underneath. You receive data on a schedule, in the format you asked for, without running any infrastructure yourself.
We are not affiliated with Coupang and we do not resell datasets. We collect public pages, we scope each project to what a client actually needs, and we say plainly when part of a scope is not viable rather than promising it and quietly delivering thin rows.
A productId identifies the detail page. An itemId identifies a variant on that page, such as one colour in one size. A vendorItemId identifies one merchant's offer on that variant, and it is the level that carries the price, the shipping fee and the stock. Coupang's seller documentation calls vendorItemId the lowest-level identifier and states it cannot be changed, while productId can change when Coupang merges or unmerges products. We store all three on every row so your history survives a merge.
The detail page shows the Item Winner (아이템위너), the merchant Coupang selects among everyone listing that product, and the payload exposes an otherSellerCount alongside it. Coupang's robots.txt disallows the /vendor-items/ and /other-seller-json paths that carry the competing offers, and it does so even for the search engines it otherwise allows. We scope offer-level work against that constraint and tell you what is viable before you commit to a project.
Yes. In the listing payload the Rocket badge arrives as an image URL inside rocketArea rather than as text, so we classify it from the badge asset. That separates Rocket Delivery (로켓배송), where Coupang owns the stock, from Seller Rocket (판매자로켓), where a merchant's stock sits in a Coupang fulfilment centre but the merchant still sets the price. Rocket Fresh (로켓프레시) and Wow membership carry their own flags, including freshEligible, dawnOnly and wowOnlyInstantDiscountRate.
Yes, as a separate job. Taiwan runs on www.tw.coupang.com with the same /vp/products/{id} grammar, but its numeric identifiers occupy a different and much longer space, so a Korean productId will not resolve there and the two catalogues cannot be joined on id. The robots posture differs too: the Taiwanese file is broadly permissive, while the Korean one disallows every user agent it does not name. Coupang's Japanese storefront closed in early 2023.
Coupang publishes an Open API, but it is a vendor API: it serves a merchant its own catalogue, orders and settlement, not the marketplace as a shopper sees it. Competing offers, the merchant currently on display and a category listing are not available through it, so reading them means extracting the storefront. Once that is running, daily is the usual cadence for price and stock, hourly is workable for a narrow watchlist, and weekly is enough for catalogue mapping. Output is CSV, JSON, XLSX or an API endpoint of ours. Because we keep dated snapshots rather than overwriting, a change in price, in the merchant on display, in the arrival promise or in stock shows up as a series you can query, not as a value that silently replaced the last one.
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
