We scope the slice first: which categories, search terms or merchants, which delivery country prices should be resolved for, and how often it has to refresh. Then we build the crawler, run it on your schedule and hand over CSV, JSON, XLSX or a hosted API endpoint.
Records are keyed on the 24 character product id, so repeated runs deduplicate cleanly and every change becomes a diff: a price move, a merchant swap, a stock flip, a listing gone to 404. Wish serves its pages as a JavaScript shell, and the shape of the embedded state varies between requests, so we run at a measured request rate, validate response shape on every run and re-fetch failed slices instead of pushing harder. When the schema shifts, repairing the parser is our job, not yours.
The product page carries almost nothing. Fetched with a plain HTTP client it returns about five kilobytes, with no title element and a state blob holding image URLs, dimensions, a perceptual hash and is_full_product set to false. Name, price and merchant are absent. The full record lives in the JSON feed responses the app reads, and that is what a Wish scraper works from.
Storefront pages add the seller side: display_name next to a separate lowercase handle, avg_rating as an unrounded float, rating_count, percent_positive_feedback, approved_date as a Unix timestamp, a postal business_address and a secondary_seller_disclosure. Wish Local store pages differ again, carrying coordinates, a normalized address, opening year and weekly hours.
Reviews are the sharpest limit. Wish's sitemap index points at 48 product-review sitemap files, and those URLs are dead: every /product-reviews/ address sampled on 26 August 2026 returned HTTP 404 or HTTP 200 with a zero-byte body. Ratings are available as aggregates only, and a listing with rating_count 0 still reports a rating of 5.0.
Search depth is capped. The feed reports num_found, and on 26 August 2026 it came back as exactly 500 for every non-empty query we tried, so it is a ceiling, not a catalogue total. Paging is a cursor: each response carries next_offset and a feed_ended flag, and the offset does not match the row count. One sampled query returned three rows with next_offset 5, another two rows with next_offset 9. Coverage comes from slicing a query across category, price band and rating facets, whose ids read like merchant_price_10.00_20.00, rating_4, browseonomy_1902 and wss_tier_Gold, labeled Premier Merchant.
Listings expire quietly. A removed product URL returns HTTP 404 with the generic site shell and no state blob, clean enough to record as a delisting date. We drew 25 product URLs from Wish's own May 2024 sitemap and rechecked them on 26 August 2026: 15 were 404, 10 still resolved.
Everything resolves against the country a request appears to come from, so country_code, currency_code and shipping_price_country_code are pinned per run. Merchant records also carry a real postal business_address, so we ship the merchant fields you need and drop the rest at schema level.
Wish is a cross-border discount marketplace. Merchants list directly, most ship from Asia, and every product record names the country the item ships from in an origin_country field next to the seller's own business_country_code. There is no shared catalogue: two merchants offering the same item create two unrelated listings.
A product identifier is 24 lowercase hexadecimal characters. The first four bytes are a Unix timestamp equal to the listing creation time, so age is readable before a page is fetched. The canonical page is wish.com/product/{slug}-{id}, with a short form at wish.com/c/{id}. Wish's feed responses also hand out an external_mobile_url under /m/product/, and that path returned 404 on every attempt on 26 August 2026.
Internally Wish still calls a product a contest, a holdover from the app's origins. Images come from canary.contestimg.wish.com with a cache_buster query, and the page state exposes the record as initial_data.product.contest. Category browse sits at wish.com/~/{department}/{slug}, with department slugs such as fashion and home-goods. Search is wish.com/search/{query}, a storefront wish.com/merchant/{merchant_id}, and pickup partner stores sit under wish.com/local/.
Ownership changed in 2024. ContextLogic sold the Wish platform to Singapore-based Qoo10, closing on 19 April 2024. As checked on 26 August 2026 the storefront still runs under the Wish name, and its page state listed 61 shipping countries against 253 billing countries.
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
Most teams scrape Wish for the price floor. The useful question is not what Wish charges, it is how far below your own shelf price the same or a near-identical item is offered, by which merchant, and shipped from where. Both halves of that answer sit on one record: the price and origin_country.
Because listings are seller-owned rather than catalogue-owned, one design appears many times under different merchants, titles and Wish prices. Grouping those by image hash, tag set and price band turns a scatter of listings into a supply picture: how many sellers carry a product, what spread they price it at, which of them hold a Premier Merchant badge and which sit lower in Wish Standards.
Merchant records make the seller side measurable. business_country_code, approved_date and the postal business_address separate a long-running operation from an account approved last month, and rating_count read against percent_positive_feedback gives a volume-weighted view rather than a bare star average.
For brand protection work the value is coverage and dating. Cheap cross-border marketplaces are where lookalike goods surface early, and a scheduled crawl over your brand terms and product tags leaves a dated record of what was listed, at what price, by which merchant, on which day.
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 scraping team. We write the crawler, host it, watch it and repair it when the site changes, and you receive data on a schedule in a format your systems already read. No infrastructure on your side, no proxy accounts, no maintenance backlog. If a field you asked for is not public, or a slice is not reachable at the volume you need, we say so during scoping rather than after the build.
Wish publishes an API, but it is merchant-facing. The Wish Marketplace V3 API at merchant.wish.com uses OAuth 2.0, and the documentation states plainly that the client is an app wanting to access a merchant's data, and that the person granting permission holds a merchant account on Wish. It reads and writes a seller's own listings, orders and shipments. Nothing in it reads another seller's catalogue: an unauthenticated call to any path under merchant.wish.com/api/v3/ returns HTTP 400 with the message Missing access token in authorization header. Unless you are the merchant, public Wish data is collected by scraping the storefront.
Ratings yes, review text no. Every product record carries rating, rating_count, rating_spread and a rating_class string, and merchant records carry avg_rating and percent_positive_feedback. Individual review text is another matter. Wish's sitemap index points at 48 product-review sitemap files, and the /product-reviews/ URLs inside them returned either HTTP 404 or an empty HTTP 200 body on every one we sampled on 26 August 2026. One caution on the aggregates: a listing with rating_count 0 still reports a rating of 5.0, so unrated items have to be filtered out or they will pull an average upward.
By the 24 character hexadecimal id at the end of the URL. The slug in front of it is generated from the title and changes when the merchant edits it, so it is not a key. The id is, and its first four bytes decode to a Unix timestamp equal to the listing creation time, which gives an independent check on listing age and on relisted inventory. The same identifier format is used for merchants, taxonomy tags and Wish Local stores, so one join key covers the whole dataset.
Yes, from two separate fields. Each product record carries origin_country, the country the item ships from, and the attached merchant block carries business_country_code. The storefront page adds a full postal business_address and a secondary_seller_disclosure noting that a merchant may use another entity or seller to supply orders placed on Wish. Those fields do not always agree, and the disagreement is often the interesting part, so we deliver all of them rather than collapsing them into one column.
The URL starts returning HTTP 404 with the generic site shell and no product state, which is unambiguous enough to record as a delisting date rather than a gap in the run. That matters more here than on most marketplaces: we sampled 25 product URLs from Wish's own May 2024 sitemap on 26 August 2026 and 15 were already 404. If you want history, the crawl has to run on a schedule from the start, because a removed listing leaves nothing behind to reconstruct.
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
