SSENSE Product Scraper

Scrape products from SSENSE, the luxury fashion retailer: search by keyword, browse the men's or women's catalogue, follow designers and categories, or watch the sale section. Paste any store URL to walk it directly.

Every row carries the selling price and the regular (undiscounted) price, with the discount percentage computed, so the retail-versus-sale pair is on every record from the listing page itself. The product description is one toggle away.

What you get

Field	Meaning
recordId / productId	The store's own product id, stable across runs
title / brand / sku	Product name, designer, style code
price	The current selling price
regularPrice	The regular (undiscounted) price
onSale / discountPercent	True when the selling price is below the regular price, and by how much
currency	The currency the row was quoted in
inStock	Availability as the store reports it on the page
gender / category / categoryIds	Section, product type keyword and the store's category ids
imageUrl / url	Product image and product page
description	Product description (with Fetch product details on)
changeType / changedFields / firstSeenAt / lastSeenAt	Incremental-mode change tracking fields

How to use it

Search mode (default): give it search terms and it walks the store's own search results. Combine with the Section, Category, Designers, Sale only and price filters; every filter narrows what the store itself serves, except the price bounds, which are applied to the rows the run reads.

URL mode: paste any store URL. A product URL returns that single product in full. A browse, category, designer or sale URL is walked page by page, and the pasted URL decides its own scope: the price and ordering filters still narrow what the run keeps, while the category, designers and sale only filters are search mode only. Add ?page=3 to a browse URL to start from that page.

The sale axis is a first-class facet: turn on Sale only (or paste a sale URL) and the run rides the store's own sale pages, including their category and designer combinations. Combined with Incremental mode this makes a plain daily sale watch: first run returns everything as NEW, later runs return only what changed, and a price move is reported as UPDATED.

Notes on scope

• A search term is never combined with a designer facet in one request, the store refuses that combination; a designer scope walks the designer's full page instead.
• A designer slug the store does not know would silently redirect to the full catalogue. The actor detects that redirect, refuses the page, and fails the run loudly rather than returning a wider scope than you asked for.
• Prices are quoted in the currency of the country the connection exits from; every row states its own currency.

Output

Dataset rows are flat JSON. Example (illustrative placeholder, not a real product):

{
  "recordId": "00000001",
  "rowType": "product",
  "productId": "00000001",
  "title": "Sample Name Wool Coat",
  "brand": "Sample Designer",
  "sku": "000000S00000",
  "price": 890,
  "regularPrice": 1290,
  "onSale": true,
  "discountPercent": 31.0,
  "currency": "USD",
  "inStock": true,
  "gender": "men",
  "category": "coats",
  "imageUrl": "https://example.com/images/sample-coat.jpg",
  "url": "https://www.example.com/en-us/men/product/sample-designer/sample-name-wool-coat/00000001",
  "scrapedAt": "2026-01-01T00:00:00Z"
}

With Incremental mode on, rows also carry changeType (NEW, UPDATED, UNCHANGED, REAPPEARED, EXPIRED), changedFields, firstSeenAt and lastSeenAt. Resume from a previous run continues one interrupted crawl without returning or billing the records it already returned.

Limits and costs

• maxItems is the single cap on a run (0 = unlimited). maxPages is an optional safety bound per source.
• Fetch product details adds the product description per record. It is a paid extra (the Product description event on the pricing tab); the price pair, stock state and images are on every row either way.
• Emit unchanged and Emit expired return, and bill, extra rows; leave them off unless you want full snapshots or expiry tracking.

Send results into your apps (MCP connectors)

Results can be piped into the apps you already use through Model Context Protocol (MCP) connectors, as an optional side channel. This never changes the dataset output.

• mcpConnectors: authorize a connector under Apify, Settings, API & Integrations, then select it here. Notion receives a page per record; other connectors receive a best-effort write or digest. Each connector gets a condensed summary per record; the complete record always stays in the dataset.
• notionParentPageUrl: the Notion page under which record pages are created. Required for the Notion connector, ignored by the others.
• maxNotifyListings: cap on records written to each connector per run.

Compute

This actor reads pages over plain HTTP; 512 MB of memory is the default and is plenty. A minimal run finishes in well under a minute.