KLEKT Sneaker & Apparel Resale Scraper

Scrapes KLEKT (klekt.com) — Europe's leading authenticated sneaker and apparel resale marketplace. Returns structured product records: brand, SKU, description, market prices (last sold / lowest listing / highest bid), size, box condition, availability and images.

What it does

• Browse mode (default) — walks KLEKT's own catalogue page by page, with filters for section, brand, category, size, box condition, listing type, availability and price. Run it with no input at all and it returns trending products straight away.
• Product URLs mode — paste KLEKT product page URLs, get the full record for each (JSON-LD product data + the on-page market-price blocks).
• Full catalogue mode — stream the entire KLEKT catalogue from the official sitemaps (about 15,000 products) and enrich each product.
• Send results into your apps (MCP connectors) - optional.

Input

Field	Description
Scrape mode	"Browse the catalogue", "Product URLs" or "Full catalogue via sitemaps". Defaults to Browse.
Product URLs	KLEKT product page URLs, one per line (Product URLs mode).
Catalogue section	Which section Browse walks: Trending, Used / pre-owned, On sale, Drops, Upcoming, Gift cards.
Brand	Narrow to one brand (e.g. Nike), written the way KLEKT displays it.
Brand line / model family	Optionally narrow further inside a brand (e.g. Dunk Low).
Product category	Sneakers, Streetwear or Accessories.
Size category	Men, Women, Youth or Default.
Size system	Which system the Size below is written in (US, UK, EU, ...). Required together with Size — a size on its own is ignored by KLEKT.
Size	One size in the system chosen above (e.g. 10, 44, M4/W6).
Box condition	Good, Missing lid, Damaged, No box, Replacement box.
Listing type	Used or New with defect — only applies to the Used section.
Availability	Available, Express dispatch or Used available.
Minimum price (EUR)	Whole euros. 0 or empty = no lower bound.
Maximum price (EUR)	Whole euros. 0 or empty = no upper bound.
Fetch product details	On by default. Browse mode only: off there keeps the lighter catalogue row and skips the enrichment charge. Product URLs and Full catalogue mode have no catalogue row, so they always fetch the product page (the log says so if you switch it off) — otherwise you would be billed a product record for a row holding nothing but the URL you supplied.
Max items	Stop after this many products. 0 = unlimited.
Max catalogue pages	Optional safety bound on the Browse walk (20 products per page). 0 (the default) = no page bound: the walk stops by itself at the end of the section, or earlier when Max items is reached.
Resume from a previous run	Paste a previous run ID or dataset ID to continue a large crawl without returning, or charging for, records already collected there.
Incremental changes for scheduled runs	Turn on for recurring monitoring: the first run returns everything as NEW, later runs only NEW / UPDATED (and REAPPEARED) records. See the section below.
State key	Optional name for an incremental monitoring campaign; keeps state stable across input tweaks, or deliberately shares it.
Emit unchanged records	Off by default. On, incremental runs also return unchanged rows marked UNCHANGED (a full snapshot — returns and bills extra rows).
Emit expired records	Off by default. On, a run that fully scanned the tracked scrape also returns rows that vanished, marked EXPIRED.
Proxy configuration	KLEKT is open — the default Apify proxy is fine. Whichever proxy groups you select are the ones used, and turning Apify Proxy off really does connect directly.
MCP connectors	Optionally pipe results into Notion / Linear / Airtable / Apify. Never changes the dataset.
Notion parent page	The Notion page under which one page per product is created (Notion connector only).
Max products to export per connector	Cap on products written to each connector per run. Does not affect the dataset.

Schema keys for API/task-input use: mode, productUrls, strategy, brand, brandLine, productCategory, sizeCategory, sizeMetric, size, boxCondition, listingType, availability, priceFrom, priceTo, fetchDetails, maxItems, maxPages, resumeFromRunId, incrementalMode, stateKey, emitUnchanged, emitExpired, proxy, mcpConnectors, notionParentPageUrl, maxNotifyListings.

About the filters

The browse filters apply to Browse mode only — Product URLs mode and Full catalogue mode fetch specific product pages, so nothing in that section changes what they return.

Every filter offered here was checked against the live site, and the actor refuses to pretend. If KLEKT would silently ignore a setting, the actor drops it and says so in the run log rather than sending it and returning an unfiltered result:

• Size is dropped unless a Size system is chosen too (KLEKT only applies the pair).
• Listing type is dropped outside the Used section, where KLEKT either returns nothing or ignores it.
• An Availability or Catalogue section value outside the offered list is replaced/dropped — KLEKT would otherwise return its entire catalogue.
• Non-numeric price bounds are dropped.

Output

One record per product (Browse on Trending / Drops / Upcoming and the two URL modes) or per marketplace listing (Browse on Used / On sale):

name, brand, sku, slug, url, description, colorway, priceAmount/priceCurrency, lastSoldPrice, lowestListingPrice, lowestListingSize, highestBid, size, boxCondition, listingType, availability, releaseYear, images, imageUrl, seller, detailScraped, id, type.

priceAmount is the catalogue price — the number KLEKT's own Min / Max price filter matches on — so a price-bounded run always returns rows inside the range you asked for, whether or not detail enrichment is on. For a Used or On sale row that is the listing's own asking price. In the two URL modes, where there is no catalogue row, it falls back to the product page's most recent verified sale, otherwise the cheapest live listing.

The product page's own market numbers are always delivered alongside it, under their own keys: lastSoldPrice (the most recent completed sale of the model — frequently well above the current catalogue price), lowestListingPrice and highestBid.

Sample values below are illustrative placeholders, not live listings.

{
  "id": "00000000-0000-0000-0000-000000000000",
  "name": "Sample Runner 1 'Example' (2024)",
  "brand": "Sample Brand",
  "sku": "XX1234-000",
  "url": "https://klekt.com/product/new/sample-runner-example-2024",
  "priceAmount": 125.0,
  "priceCurrency": "EUR",
  "availability": "InStock",
  "detailScraped": true
}

Resume and recurring updates (incremental mode)

Two related but different features live in the 🔁 Resume and recurring updates section:

• Resume from a previous run (resumeFromRunId) continues ONE specific interrupted run: paste its run ID (or dataset ID) and records already collected there are neither returned nor billed again.
• Incremental changes for scheduled runs (incrementalMode) is for running the same scrape again and again — for example daily. The first run returns everything as NEW. Later runs compare every scraped product against the previous run's saved baseline and return only what changed: NEW products, UPDATED ones (with the changed fields listed), and REAPPEARED ones for products that come back after vanishing. Unchanged products are suppressed entirely unless Emit unchanged records (emitUnchanged) is on.

With Emit expired records (emitExpired) on, a run that scanned the tracked scrape to its natural end also returns every previously-seen product it can no longer find, marked EXPIRED. That guarantee is deliberately strict: a run stopped early by Max items, seeded from Resume, or interrupted by a refused connection cannot tell "gone" from "not reached yet", so it skips EXPIRED detection and keeps the previous state as-is. The run log always states which of the two happened.

Incremental state is kept in the actor's own key-value store, keyed on the scrape itself (mode, section, filters, detail setting) — two different scrapes never mix state. Set State key (stateKey) to name a campaign explicitly, e.g. to keep monitoring stable while tweaking an unrelated input, or to deliberately share one baseline across differently-configured runs.

Records classified in incremental mode carry four extra fields: changeType (NEW / UPDATED / UNCHANGED / REAPPEARED / EXPIRED), changedFields, firstSeenAt and lastSeenAt. A normal (non-incremental) run's output shape is untouched.

Send results into your apps (MCP connectors)

Optionally pipe scraped KLEKT products into the tools you already use via Model Context Protocol connectors (Notion, Linear, Airtable, Apify). Authorize a connector under Apify → Settings → API & Integrations, then select it in mcpConnectors. Notion gets a rich page per product (set notionParentPageUrl to the page they should be created under); other connectors get a best-effort write or digest. Use maxNotifyListings to cap how many are sent — that number is what is actually delivered, and the run log reports how many each connector took and whether it accepted them.

This is an optional side channel: it never changes the dataset output, and a connector error — including a connector that accepts the connection and then goes silent — is logged as a warning without failing or stalling the run. The export runs after every row is already in the dataset and is time-bounded, so it can never hold the run open.

Notes

• KLEKT authenticates every sale itself (fixed marketplace model), so records carry the platform as seller rather than individual seller contacts.
• Pricing fields reflect what the product page exposes: lastSoldPrice is the most recent verified sale; lowestListingPrice and highestBid appear when the page shows them.
• brand is only ever read from the product itself — it is never a copy of the Brand filter you typed. KLEKT's catalogue rows carry no brand, so with Fetch product details off the field is empty; enrichment fills it from the product page. Pre-owned listing pages (/product/used/<id>) do not publish a brand at all, so it can stay empty on Used / On sale rows.
• Filters that a section would silently ignore are dropped and reported in the run log instead of being sent for show. The Gift cards section ignores every catalogue filter, so a filtered Gift cards run returns the whole section and says so.
• No login required. The source is open to standard connections; a proxy is optional.