Wildberries Scraper — Products & Reviews | Парсер Вайлдберриз

Scrape Wildberries (wildberries.ru) product data as clean JSON: search catalogs, product cards, prices and reviews. A product data API for the Russian marketplace — API-level and fast, no brittle browser automation. Парсер Вайлдберриз: товары, цены, отзывы.

What you get

Give it a search phrase or product IDs. The dataset contains two kinds of item, tagged by a type field. Products and reviews are separate rows, joined by nmId / imtId.

Product:

{
  "type": "product",
  "nmId": 1097975275,
  "imtId": 2227481309,
  "name": "Wireless Headphones XYZ",
  "brand": "XYZ",
  "supplier": "TechLine LLC",
  "price": 2490,
  "basicPrice": 3990,
  "rating": 4.7,
  "feedbacks": 1523,
  "url": "https://www.wildberries.ru/catalog/1097975275/detail.aspx"
}

price is what the customer actually pays; basicPrice is the price before discount. Both are in roubles (the raw Wildberries API returns kopecks — we convert). A product that is currently unavailable has no price at all rather than a zero, so price may be absent.

Review (only when includeReviews is on):

{
  "type": "review",
  "imtId": 2227481309,
  "nmId": 1097975275,
  "reviewId": "DdAOL5cB0x_abc",
  "text": "Great sound, fast delivery.",
  "pros": "battery life",
  "cons": "",
  "stars": 5,
  "date": "2026-07-13T08:48:38Z",
  "size": "M",
  "color": "black",
  "author": "Anna",
  "photos": 2,
  "hasVideo": false,
  "sellerAnswer": "Thank you for your review!",
  "url": "https://www.wildberries.ru/catalog/1097975275/detail.aspx"
}

pros and cons are separate fields from text and are often empty — for sentiment work you want all three. photos is a count, and both photos and hasVideo are absent when the review has no media. sellerAnswer is the seller's public reply, when there is one.

Use cases

• Price & assortment monitoring across Wildberries catalogs.
• Review mining for product research and sentiment.
• Market intelligence for e-commerce teams that need WB data in a clean, English-documented API.

Input

Field	Type	Description
queries	string[]	Search phrases to resolve into product catalogs.
productIds	string[]	Specific nmId values to fetch full cards for.
includeReviews	boolean	Also fetch reviews. Reviews are charged as a separate event.
maxReviewsPerProduct	integer	Most recent reviews to keep per product (default 20).
dest	string	Region code affecting price and delivery estimates (optional).
maxItems	integer	Hard cap on scraped products.
proxyConfiguration	object	Proxy rotation. On by default — leave it on (see reliability numbers below).

How to use it

1. Click Try for free / Start on this page.
2. Put one or more phrases into Search queries (for example наушники), or paste specific article numbers into Product IDs (nmId) if you already know what you track. You can use both at once; searches and IDs are collected into the same dataset.
3. Optionally switch on Include reviews and set Max reviews per product. Reviews arrive as separate rows and are billed as a separate event, so leave it off if you only need prices.
4. Set Max items to cap the run. It counts products and reviews together.
5. Leave Proxy configuration on Apify Proxy — the reliability numbers below are measured with rotation on, and a single unproxied IP degrades badly.
6. Run it. Watch the Output tab: the Products view shows catalog rows, the Reviews view shows review rows. Export as JSON, CSV, Excel or pull the data over the API.

To run it on a schedule, use Apify Schedules; to call it from your own code, use the Apify API or one of the official clients. Every field in the output is described in this Actor's dataset schema, so AI agents calling it through the Apify MCP server get typed field metadata rather than raw JSON.

Why this scraper

• Measured reliability, honestly reported. Running on Apify with proxy rotation: 100% task success across 50 runs (80 tasks, 500 items; 4 transient blocks absorbed by retries). The same code from a single unproxied datacenter IP degrades instead — four 50-run measurements gave 91.2%, 98.75%, 90.14%, 77.94% in that order, and a 12-hour rest did not restore it. That contrast is why this Actor is built for rotation, and why you should keep proxy on for anything beyond a trial run. Transient blocks are retried with backoff instead of being silently dropped, and a run that gets truncated reports the truncation rather than passing it off as a complete result.
• It knows where Wildberries lies. The search endpoint does not end a result set with an empty page — it starts serving page 1 again, and it sometimes answers HTTP 200 with a substituted body. Both are detected explicitly, so you get a truncated dataset reported as a failure rather than presented as a complete run.
• English documentation — every field explained, no guesswork.
• Schema-validated output — every item is checked against a schema before it reaches your dataset, so a change on Wildberries' side surfaces as a loud failure, not as undefined in your price feed.

Limits (honest)

• Reviews are capped at 1000 per product by Wildberries itself, newest first, and that endpoint has no pagination. For a product with 130k reviews you get a recent-1000 sample, not the full corpus. The product-level rating and feedbacks count still reflect all reviews.
• Search results are finite. Past the last real page Wildberries repeats page 1; the scraper stops there. Very broad queries will not yield their full advertised total.
• Night window (00:00–06:00 UTC): search is throttled harder. Wildberries rate-limits its search endpoint noticeably more at night (early morning Moscow time) — measured on weeks of nightly runs, not guessed. The Actor absorbs this with patient retries and, when retries alone are not enough, falls back to a mobile proxy for the search step, so night runs still succeed — they just take longer than the same run during the day. Product cards and reviews are not affected. If a night search still fails after every retry, the run reports a failure instead of passing off a truncated dataset as complete — and with per-result pricing a slower run does not cost you more.
• Public data only; no login, no bypassing of access controls. Requests are paced to respect Wildberries' rate limits.
• Price and delivery estimates vary by dest region — the scraper pins one region per run so your time series stays comparable.

Pricing

Pay-per-event: a charge per run start, a charge per scraped product, and a separate charge per scraped review (so runs without includeReviews never pay for review capacity). See the Store page for current rates.

FAQ

Do I need a Wildberries account or an API key? No. The Actor reads only publicly available data and never logs in.

Can I use the official Wildberries API instead? Only for your own shop. The official seller API (dev.wildberries.ru) requires a seller token and returns data about your own store — the public catalog of other sellers is not available through it. This Actor reads the public catalog, which is exactly the part the official API does not cover.

Why is price sometimes missing? Because the product is currently unavailable. Wildberries reports no price at all in that case, and the Actor passes that through instead of inventing a 0 that would poison your averages.

Why do I get fewer products than the total Wildberries advertises? Wildberries does not end a result set with an empty page — past the last real page it starts serving page 1 again. The Actor detects that repetition and stops, so a broad query returns the pages that actually exist rather than looping forever.

Why do I get at most 1000 reviews for a product with far more? That is Wildberries' own cap on the reviews endpoint, newest first, and it has no pagination. The product-level rating and feedbacks count still reflect every review.

Can I get reviews without products? No — reviews are addressed by imtId, which comes from the product card, so products are always fetched first. Setting maxReviewsPerProduct low keeps the review cost small.

Does the region code matter? Yes. Prices and availability differ by region, so the Actor pins one dest per run. Leave it empty for the Moscow default and keep it stable if you are building a price time series.

Why is my scheduled night run slower than the same run during the day? Because Wildberries throttles its search endpoint harder between roughly 00:00 and 06:00 UTC. The Actor retries with backoff and falls back to a mobile proxy when needed, so night runs complete — just more slowly. If timing is flexible, schedule search-heavy runs outside that window; you pay per result either way, so the slowdown costs nothing extra.

Can I run it without a proxy? You can, but you should not. Measured on the same code: 100% task success across 50 proxied runs, versus a decline to 77.94% from a single unproxied datacenter IP that a 12-hour rest did not repair.

Other Actors by ActorForge

• Avito Real Estate Scraper — full property inventory from Avito with freshness stamps, for new-listing alerts and comps.
• Lazada Reviews Scraper — ratings, review text and buyer media from Lazada across the SEA marketplaces.

Need a marketplace we do not cover yet, or card-level enrichment beyond what is listed here? Open an issue from the Actor's page and tell us what you need.

Disclaimer

This is an unofficial scraper. It is not affiliated with, endorsed by, or connected to Wildberries in any way. It collects only data that Wildberries publishes publicly, without logging in and without circumventing access controls. You are responsible for ensuring your use of the collected data complies with applicable law and with Wildberries' terms.

Changelog

See the repository CHANGELOG.md.