Grailed Marketplace Scraper

Scrape Grailed, the menswear and womenswear resale marketplace: search by keyword, walk the store's own category, designer, condition and size facets, watch sellers, or paste any store URL to walk it directly.

Every row carries the current ask price and the ask history the store keeps (each prior asking price on the listing), plus the seller's score card and the shipping bands. The listing description, the measurement table and the photo set are one toggle away.

What you get

Field	Meaning
recordId / rowType	Stable id and the kind of row: product, seller or review
title / designer / designers	Listing name and designer(s)
price	The current ask price
originalPrice / askHistory	The oldest ask on the listing and every prior ask the store keeps
size / conditionLabel / categoryPath	Size, the store's own condition grade, and the category path
sellerRating / sellerRatingCount / sellerSales	The seller's score card, as the listing card carries it
coverPhoto / shippingUs	Cover image and the US shipping band
description / measurements / photos	Listing page fields (with Fetch listing details on)
changeType / changedFields / firstSeenAt / lastSeenAt	Incremental-mode change tracking fields

Seller rows add the full profile (rating breakdown, badges, location, member since). Review rows carry the rating, the note, the tags and the listing the review refers to.

How to use it

Search mode (default): give it search terms and it walks the store's own search feed. Combine with the department, category, designer, condition, size and price facets; every one of them narrows the feed the store itself serves, they are not applied after the fact.

Sellers: name usernames (or paste profile URLs) to read seller profiles. Two toggles add the seller's reviews as their own rows, and a walk of the seller's on-sale listings as normal product rows.

URL mode: paste any store URL. A listing URL returns that single listing in full. A category or designer 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 catalogue facets are search mode only.

Notes on scope

• Sold listings are excluded from the store's searchable catalogue, so there is no sold-comparison surface to read; rows still carry the sold fields for when the store populates them. The ask history on each row is the price context the store does expose.
• The store's own feed serves at most 25 pages of 40 rows per scope, the same ceiling its own website lives with. Reaching deeper into a large catalogue means narrowing the scope with facets.
• A category or designer name the store does not serve never widens the scope: an unknown category stops the run with a clear message, and an unknown designer simply matches nothing (reported as an empty search).
• A price cut IS a change: with Incremental mode on, a moved ask price reports the row as UPDATED with price in changedFields.

Output

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

{
  "recordId": "00000001",
  "rowType": "product",
  "listingId": "00000001",
  "title": "Sample Designer Sample Wool Sweater",
  "designer": "Sample Designer",
  "price": 210.0,
  "originalPrice": 260.0,
  "askHistory": [260.0, 235.0],
  "size": "m",
  "condition": "is_gently_used",
  "conditionLabel": "Gently Used",
  "categoryPath": "tops.sweaters_knitwear",
  "department": "menswear",
  "sold": false,
  "sellerUsername": "sample_seller_00",
  "sellerRating": 4.9,
  "sellerRatingCount": 128,
  "sellerSales": 340,
  "coverPhoto": "https://example.com/images/sample-sweater.jpg",
  "shippingUs": 12.0,
  "url": "https://www.example.com/listings/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, defaulting to 20; set 0 for unlimited. maxPages is an optional safety bound per source.
• Fetch listing details adds the description, the measurement table, the photo set and the deeper seller fields per listing. It is a paid extra (the Listing details event on the pricing tab); the ask price, the ask history and the score card are on every row either way.
• Fetch seller reviews emits each review as its own dataset row, billed as one.
• 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.