Grailed Scraper: Sold Prices & New Listings

Watch a search, get only what's new. This actor runs your search against Grailed's own first-party Algolia search — the largest dedicated resale marketplace for menswear and streetwear — and returns one clean row per listing: price, designer, size, condition, and Grailed's own price-drop history. Search sold listings too, for sold-price comps without eBay's login wall. Turn on monitoring and it becomes a watchlist: new listings and price drops since your last run, charged per new row, free on quiet days. Schedule it hourly and send the results to Discord, Slack, Google Sheets, or n8n.

Who it's for

A reseller checking what a piece is actually worth before buying or flipping it wants real sold prices, not asking prices — Grailed's sold index gives you that without eBay's login-walled "completed listings" search. A buyer watching for a specific designer, size, or price band wants a live feed of new listings the moment they post, without refreshing the search page by hand. A market-research or pricing team tracking resale value for a product category, or a Sheets/n8n workflow that reacts the moment something new is posted or a price drops, gets the same shape here: paste a list of search terms, get back a flat row per listing, and pay only for listings actually returned — a search that finds nothing costs nothing.

Why this one

• Sold-price comps without eBay's login wall. Grailed exposes its own sold-listings index (sold_at desc) with real sale prices and dates — set "Listing type" to "Sold listings" for a comps feed. eBay's own completed/sold search has needed a login since 2026-07-22, which is why this is rare among scrapers right now.
• Grailed's own price-drop history, no monitoring required. Every listing carries its own nativePriceDropCount and originalPrice straight from Grailed's data — the seller's own markdown history, available even with monitoring off.
• Monitoring first, not a one-off dump. Turn on "Only return results that are new, or dropped in price" and this actor becomes a watchlist: it remembers every listing ID it has already shown you, and only bills you for what's actually new or has dropped in price (against what this watchlist has seen) since the last run. A quiet run still finishes and costs only the base run fee.
• Reads Grailed's own structured search data. Every field comes from Grailed's first-party Algolia index — the same data that powers grailed.com's own search page — not text scraped from rendered HTML, so price, size, condition, and designer are exact, typed values.
• Never charged for a miss, or a quiet monitoring run. A search that finds nothing, or a scheduled watchlist run where nothing changed, still gets a row explaining what happened — and costs nothing.

What you get

One row per listing by default (turn off "Expand rows" in Advanced to get one row per search instead, with the listings nested under listings).

Deselect any field in the Input tab's column picker to drop it from every row — query, found, status, message, and scrapedAt always stay.

priceDropCount (the search-level monitoring summary) and nativePriceDropCount/originalPrice (the per-listing field, from Grailed's own permanent history) are deliberately different things — see "Monitoring / only new results" below.

Sold comps and sell-through

Turn on "Include sold comps and sell-through stats" and every search also fetches Grailed's own sold-listings index for the same keywords and filters — up to "Max sold comps to fetch" (50 by default, 200 max), newest sale first — regardless of what "Listing type" is set to. Each sold comp comes back as an ordinary row: isSold: true, soldAt, soldPrice, and daysToSell (the days from postedAt to soldAt, when both are present). Sold comps are listings too — they're billed as ordinary listing rows, at the same per-listing price as an active listing, not a separate event.

Every row of a search with sold comps on also carries sell-through summary columns, computed from everything the run actually fetched (not just what's returned after any monitoring filter): activeCount and soldCount (how many of each this run fetched), sellThroughRate (

soldCount / (soldCount + activeCount)

Honesty note. Grailed's sold index reflects whatever Grailed itself marks sold — that includes offers accepted off-platform (e.g. a seller and buyer agreeing outside Grailed's own checkout) as well as genuine in-app sales, and Grailed doesn't distinguish the two. sellThroughRate and the median prices describe this run's fetched window, not Grailed's full sold history for that search — narrow your search (a specific designer/size/category) if you want the window to represent the whole market for that niche rather than a slice of it.

Example: {"searches": ["carhartt jacket"], "includeSoldComps": true, "maxSoldComps": 100} returns active Carhartt jacket listings plus up to 100 recent sold comps in the same run, with sell-through and median-price-gap columns on every row.

Related actors. vinted-listing-lookup's own monitoring infers a sold signal indirectly, by noticing a listing has gone (delisted, most often sold); Grailed exposes its sold history directly via a real sold index, so this actor's sold comps are Grailed's own confirmed sold rows, not an inference. poshmark-listing-lookup has the same sold-comps shape for Poshmark, with its own honesty note (Poshmark shows the last asking price, not a negotiated final price).

Pricing

• Listing returned: $2 per 1,000 listings

Plus a $0.00005 start fee per run. Each event above is billed independently, only when it actually returns data — misses (found:false) are never charged.

No upgrade event — every field this actor declares comes from the same Algolia hit, with no per-listing page hop.

Sold comps

Set "Listing type" to "Sold listings" (or "Both") to search Grailed's own sold-listings index instead of (or alongside) active listings. Each sold row carries soldPrice and soldAt straight from Grailed's own record of the sale — a real comps feed, not an asking-price guess. This is genuinely rare among resale scrapers right now: eBay's own completed/sold search has sat behind a login wall since 2026-07-22, and the last signed-out fallback closed 2026-08-19, so a logged-out actor can't reach that data at any proxy tier. Grailed doesn't have that wall.

For listingType: "both", your "Most listings to return per search" budget is split evenly across the active and sold indexes, and each listing's isSold flag tells the two apart in one combined result.

Want sold comps alongside an active search, plus sell-through and median-price-gap stats, without switching "Listing type" away from "Active listings"? See "Sold comps and sell-through" above.

Monitoring / only new results

Turn on "Only return results that are new, or dropped in price" and a search line becomes a watchlist instead of a one-off dump:

• A listing counts as new the first time its Grailed listing ID is returned by this watchlist. For listingType: "sold", that reads naturally as "newly sold since the last run" — a sold-comps feed rather than a listing alert.
• A listing counts as a price drop when its price falls by at least "Minimum price drop" (5% by default) since this watchlist last saw it — measured against the most recently seen price, so a listing that drops twice is compared against its latest price each time, not its original one. This is separate from Grailed's own nativePriceDropCount/originalPrice fields, which reflect Grailed's permanent record and work whether or not monitoring is on.
• Already-seen, unchanged listings are dropped before you're billed. A quiet run — nothing new, nothing cheaper — still finishes and returns one free row with monitorStatus: NO_NEW_ROWS, so a scheduled task shows it actually ran.
• The first run has nothing to compare against. By default it returns everything it finds as "new" (so you see your whole current search result once). Turn on "Seed silently" to instead have the first run bank everything quietly with zero rows and zero charge, and start alerting from the second run on — this is what stops a fresh watchlist from firing a hundred "new listing" messages into your Discord channel on day one.

Schedule recipe. Save this actor as an Apify Task with deltaMode: true and a deltaName you choose, add an hourly (or daily) Schedule, and point the task's webhook at Discord, Slack, Google Sheets, or an n8n/Make webhook URL to get pinged only when something actually changes.

Window limitation. A new listing or price drop is only ever seen while it's still inside what a run actually fetches (your "Most listings to return per search" budget, filtered by any designer/size/category/condition/price filters you set). If a listing falls out of that window between runs, this actor has no way to notice it. Keep searches reasonably narrow — a specific designer, a tight category, a price band — rather than one huge catch-all if you want reliable new/price-drop coverage.

How to use

1. In the Apify Console. Open the actor page and click Start — the searches field is already pre-filled with a working example. Results land in the run's dataset as soon as each item is found.
2. Via the API. Call it directly with a POST request — no Console needed once you have an API token:

   curl "https://api.apify.com/v2/acts/accountable_eel~grailed-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"searches":["carhartt jacket"]}'
   

3. On a schedule. Save this actor as an Apify Task with the input you want, then add a Schedule (hourly, daily, weekly) so it runs on its own — no server of your own required.

4. Turn on "Only return results that are new, or dropped in price" under Monitoring once you want a watchlist instead of a one-off dump — see "Monitoring / only new results" above.
5. Set "Listing type" to "Sold listings" for sold-price comps instead of active listings.

Input

{
  "searches": [
    "carhartt jacket"
  ]
}

One search per line — any keywords, e.g. "carhartt jacket", "arcteryx beta", "rick owens". No login required. Accepted formats: carhartt jacket, arcteryx beta, rick owens.

Sample output

A search that finds nothing comes back as a row with "found": false and is never charged. A quiet monitoring run comes back as a row with "found": true, "monitorStatus": "NO_NEW_ROWS" and is also never charged.

Use it from Clay, n8n, Make, or an AI agent

This actor runs synchronously over plain HTTP — call it directly from a script, a workflow tool, or an AI agent, no Apify Console needed once you have an API token.

curl "https://api.apify.com/v2/acts/accountable_eel~grailed-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"searches":["carhartt jacket"]}'

n8n. Add an HTTP Request node: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~grailed-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body Content Type JSON, JSON Body {"searches":["carhartt jacket"]} (swap in an expression from an earlier node for a real value).

Clay. Add an "HTTP API" column: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~grailed-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body {"searches":["{{search}}"]}, mapping the row's search into the searches array.

MCP. In Claude, Cursor, or any MCP client with the Apify MCP server, ask for "Grailed Scraper: Sold Prices & New Listings | Apify" — the agent will find and run this actor.

For monitoring, point the Task's webhook (Console → your Task → Webhooks) at a Discord or Slack incoming-webhook URL, a Google Sheets automation (via Zapier/Make/n8n listening for the webhook), or an n8n/Make workflow's own webhook trigger, so new listings and price drops land wherever you actually work instead of a dataset you have to remember to check.

Tips

• Start monitoring with "Seed silently" on for any watchlist you're setting up on a schedule — it avoids a wall of "new" alerts for your entire current search result on day one.
• Keep a monitored search reasonably narrow (a designer, a tight category, a price band) — see "Window limitation" above for why a huge catch-all search misses new listings and price drops on rows that fall outside what gets fetched.
• Use designers/sizes/categories/condition to narrow a search server-side instead of filtering a big result set yourself downstream — Grailed's own facets do the work.
• originalPrice and nativePriceDropCount work on every run, monitoring or not — they're Grailed's own permanent record for that listing, not this actor's watchlist memory.
• A BLOCKED status usually clears on its own shortly; this actor doesn't need a proxy by default.

vs. piotrv1001/grailed-scraper and the rest of the field

The current Apify Store leader for Grailed, piotrv1001, has 22 users and zero reviews; several other listed Grailed scrapers haven't been updated in 4+ months. None of them expose Grailed's own sold-listings index as a comps feed, and none offer new-listing or price-drop monitoring.

Data & privacy

This actor reads public search results that anyone can see without logging in. It doesn't log in, solve CAPTCHAs, or reveal hidden contact details. Seller identity is off by default: you get a private, always-on anonymous seller hash so you can group listings by seller without a name — raw seller ID, username, and profile link are only included when you turn on "Include raw seller info". Turning that on makes you responsible for having a lawful reason to process it. Photos are output as links only, never downloaded or re-hosted. Not affiliated with Grailed.

Is this allowed? It collects the same public listing data your browser shows, for the searches you choose. It's built for monitoring a search, not for copying the marketplace. Check that your use fits Grailed's terms and your local law.

FAQ

Why is a row empty, or why does found say false? Either the input line was blank (status: BAD_FORMAT), Grailed's search key stopped working and couldn't be recovered (status: BLOCKED), or the search matched nothing on Grailed right now (status: NOT_FOUND). Check the message column for the specific reason. None of these are billed.

Am I charged for a quiet monitoring run? No. When monitoring finds nothing new and no price drops, you get one row with monitorStatus: NO_NEW_ROWS and listingCount: 0 — Actor.charge() only fires when listingCount is greater than zero.

What's the difference between priceDropCount and nativePriceDropCount? priceDropCount (on the search/parent row) is this watchlist's count of price drops it noticed this run — it's 0 unless monitoring is on. nativePriceDropCount (per listing) is Grailed's own permanent count of that listing's price history, independent of monitoring — it can be nonzero even on your very first, non-monitored run.

Can I get sold prices, not just asking prices? Yes — set "Listing type" to "Sold listings" or "Both", or turn on "Include sold comps and sell-through stats" to get sold comps alongside your active search plus sell-through rate and median-price-gap columns. See "Sold comps" and "Sold comps and sell-through" above.

Do I need to configure proxies? No, and this actor doesn't support one. Grailed's own Algolia search endpoint (where the actual listing data comes from) has no anti-bot protection in front of it and needs none. grailed.com's own homepage does sit behind a Cloudflare challenge that a proxy-less HTTP request can't clear — this actor only visits that page as a last-resort key-recovery step if Grailed ever rotates its public search key, and even that recovery attempt runs without a proxy per this build's scope.

What happens if Grailed rotates its Algolia key? This actor tries a live re-read of grailed.com once, then reports status: BLOCKED with a message that says the key appears to have rotated, rather than silently returning nothing. This shows up as a real, visible miss — not a run that quietly looks healthy while returning garbage.

Can an AI agent call this directly? Yes. It's registered on the Apify MCP server — an agent in Claude, Cursor, or another MCP client can find and run it by name ("Grailed Scraper: Sold Prices & New Listings | Apify"), or you can call the REST endpoint shown above from any script or workflow tool.