AliExpress Scraper

Scrape product data from AliExpress (aliexpress.com): search by keyword or category, or walk pasted search / category / product URLs forward page by page. Every result includes identity, price, discount, currency, rating, units sold, media, and seller fields; an optional detail step adds SKU variant tables, specifications, description, seller data and more; an optional reviews step adds per-product review records.

Covers the global storefront in 11 markets (US, UK, DE, FR, ES, IT, BR, CA, AU, NL, PL) with prices rendered in that market's currency.

Quick start

1. Mode: search - enter one or more keywords, optionally a category ID and price / free-shipping / sort filters, and set Max products total.
2. Mode: URL - paste search, category, or product URLs (/w/wholesale-...html, /category/...html, /item/<id>.html).
3. Choose whether to also fetch detail pages and/or reviews.
4. Run. Results land in the dataset; optionally pipe them into Notion, Linear, Airtable or any MCP app via the connectors section.

What each run returns

Every product record includes:

Group	Fields
Identity	productId, productUrl, productName (title), productType, categoryId
Price	currentPrice (price), originalPrice, discountPct (discountPercentage), currency
Rating & sales	ratingScore (rating), reviewCount, itemSold (totalSold), itemSoldCount (totalSoldCount)
Availability	inStock, isSponsored
Media	primaryImage (imageUrl), imageGallery (additionalImages)
Seller	sellerName, sellerCompanyName, brandName
Promotions	sellingPoints (badges such as "New shoppers save ...", "Best price ...")
Bookkeeping	fetchedAt (scrapedAt), sourceUrl, seedType, seedValue, shippingCountry

When fetchDetails is on, each product additionally carries skuList (per-variant SKU table with prices), skuPropertyList (size / color / model options), specifications, description, descriptionHtml, breadcrumbs, shipping, warranty, sellerId, sellerPositiveRate, brandId and the detail images.

When fetchReviews is on (or reviewsOnly), the actor also emits one record per review: reviewId, buyerName, rating, reviewTime, reviewContent, skuInfo (the bought variant), likeCount and any media. Products without reviews emit an empty reviews list and keep rating / reviewCount as-is (only populated when the storefront reports them).

Sample shape - values are illustrative placeholders, not from a live listing.

{
  "type": "product",
  "id": "1234567890123",
  "productUrl": "https://www.aliexpress.com/item/1234567890123.html",
  "productName": "Bluetooth Earbuds, Wireless Headphones with Noise Cancelling",
  "currentPrice": 12.99,
  "originalPrice": 45.9,
  "discountPct": 72,
  "currency": "EUR",
  "ratingScore": 4.8,
  "reviewCount": 2300,
  "itemSold": "1,000+ sold",
  "primaryImage": "https://ae-pic-a1.aliexpress-media.com/kf/S00000000000000000a.jpg",
  "sellerName": "Example Store",
  "sellingPoints": ["New shoppers save EUR 5.00", "Delivery: Aug 09 - 17"],
  "fetchedAt": "2026-08-05T08:20:40.310Z"
}

Filters

• Min / Max price - in the market's currency; below/above the range is dropped after fetching.
• Free shipping only - requests only free-shipping eligible items.
• Sort order - best match (default), best selling, newest, price low→high, price high→low.
• Minimum rating - 1-5; lower-rated products are dropped.
• Category ID - restrict a keyword search to one category.

Each filter is applied per run and also becomes part of the incremental monitoring state key (see below), so differently-filtered runs never share state.

Resume and recurring updates

Two separate features:

• Resume from a previous run - paste a run ID or dataset ID to continue an interrupted walk without re-returning (or re-billing) products already collected there. Use it to extend one large pull across separate runs.
• Incremental mode - for daily / weekly monitoring of the same search. The first run marks everything NEW; later runs return only what changed: NEW, UPDATED, REAPPEARED, and (when enabled) UNCHANGED / EXPIRED, each with changeType, changedFields, firstSeenAt and lastSeenAt. State is stored per configuration. Emit unchanged / Emit expired return and bill extra rows - leave them off unless you need a full snapshot or expiry tracking. EXPIRED is only emitted after a run that fully scans the tracked search (not a capped, resumed, or reviews-only run).

Limits

• Max products total is the one hard cap (default 3). Set to 0 for unlimited.
• Max result pages is optional; leave empty for no page limit (the run still stops at Max products total).
• Fetch full product detail and Include reviews on each product are both OFF by default and add a separate page fetch per product (slower, plus a per-product surcharge). We recommend leaving them off unless you specifically need SKU/spec/seller detail or review text - the default results-page fields already cover the common case.

Connection notes

For the best results keep the default connection group selected in the Connection section of the input. With other connection groups, runs typically return 0 results; a warning is shown at startup. The connection country is pinned to the Target market you select so prices stay in one currency.

Separately, AliExpress intermittently refuses a meaningful share of shared exit connections with a small HTTP-200 "refusal shell" page instead of real results (measured windows range from ~1 in 8 connections working to all of them working - the decision is per-connection reputation at the site's edge). The actor handles this by rotating, and the rotation is bounded and disclosed:

• Launch budget: 12 browser launches per run (the first connection plus fresh-exit retries). A clean launch is reused for every page and product of the run - rotation happens only on refusals, never per page or per case.
• Per-fetch cap: any single result page is attempted at most 5 times on the standard pool before it counts as refused.
• Fallback connection pool: after half the launch budget is spent without a single clean response, the remaining rotations continue on Apify's unblocking proxy pool (group: UNBLOCKER); the run log says so when it happens. That pool serves different exits and may price in another market's currency; it is a data-availability fallback, not a market switch.
• A refused shell is never parsed as data: refusals are counted, never billed, and never read as "end of results".
• Worst case, a fully refused run keeps failing loudly: when every connection is refused, the run FAILS with a clear error message rather than returning an empty dataset, so you can tell a real refusal apart from a genuinely empty search. If a run fails this way, simply retry it - a fresh connection is very likely to succeed. A partially refused run discloses the shortfall as a "Partial results" status message.

The test plan in .actor/test_plan.json carries a per-case retryAllowance note: each full-test case may spend the run's whole launch budget on fresh exits before it reports a genuine failure, so a case failure means the site refused every connection that run, not that the code path is broken.

Send results into your apps (MCP connectors)

The full record always stays in the Apify dataset. Optionally, the actor can also pipe a condensed, human-readable summary of each item (title + key fields flattened to plain text - not the full JSON) into apps you already use via Model Context Protocol connectors. Authorize a connector once under Apify → Settings → Integrations, then select it in the input. Three input fields control this:

• mcpConnectors - the list of authorized connectors to pipe results into (Notion, Linear, Airtable, or Apify's own MCP server). Leave empty to skip.
• notionParentPageUrl - required only when Notion is selected: the Notion page under which item pages are created.
• maxNotifyListings - a per-connector cap on how many items are exported each run (default 50); it does not affect the dataset.

Notes

• Prices are as rendered by the storefront for the chosen market and may include listing-time promotions.
• The storefront occasionally shows a "sold" figure as text (e.g. "1,000+ sold"); the numeric totalSoldCount is parsed from that text.