n11 Products & Price Scraper (Turkey)

Scrape product listings from n11.com, a top Turkish marketplace.

What you get

One row per product (recordType: PRODUCT), from a 96-field upstream record:

Group	Fields
Product	productId, skuId, groupId, productTitle, productUrl, brandName, categoryName
Price	displayPriceValue, sellerPrice, oldPriceValue, discountRate, instantDiscountPrice, instantDiscountPercentage
Price history	firstMinFinalPriceForSevenDay / …TenDay / …FourteenDay / …ThirtyDay — upstream's own rolling minimum price
Seller	sellerId, sellerNickName, isOfficialSeller
Reputation	reviewCount, totalReviewCount, satisfiedScore, score
Logistics	stock, hasCriticalStock, isFreeShipping, hasSameDayDelivery, shipmentDeliveryType, isPreSale, isImport
Ranking honesty	isSponsored, searchRank, pageNumber

Plus the full upstream object spread in verbatim, a SEARCH_SUMMARY per query, and an ERROR row per failed input — every input maps to at least one row.

The rolling minimum-price fields are the unusual part: most marketplace scrapers can only build price history by running repeatedly. n11 publishes 7/10/14/30-day minimums itself, so a single run already carries a month of context.

Example input

{
  "searchQueries": ["laptop", "kulaklık"],
  "sortBy": "PRICE_LOW",
  "maxProductsPerQuery": 500,
  "includeSponsored": false
}

Known limits — read before you buy

• 1,000 products per query, hard. n11 clamps: request page 51 and you get HTTP 200 with a full 20-row page whose currentPage is 1 — page one, re-served. Bisected exactly (page 50 honoured, page 51 clamped). Meanwhile the same response advertises pageCount: 50,907 and totalCount: 1,018,126 for laptop. Both numbers are real arithmetic and neither is reachable. The summary row carries upstreamTotalCount, upstreamPageCountClaimed, reachableRowCeiling and pageClampReached side by side so the gap is visible rather than implied.

  To cover more: narrow the query, or run the same query under a different sortBy — each ordering exposes a different 1,000-row slice.

• Only four sort values do anything. PRICE_LOW, PRICE_HIGH, REVIEWS and NEWEST measurably change the result set. BEST_SELLER, SCORE and DEFAULT return byte-identical first rows to no sort at all — n11 silently ignores an unrecognised srt rather than rejecting it. Anything else is refused by this actor at input validation, because a typo would otherwise produce plausible, wrongly-sorted data.

• No detail-page pass, and that is a finding rather than an omission. The listing row already carries both prices, discount, seller, reviews, stock, shipping and the price history. A detail pass would double the requests to re-fetch what is in hand.

• Sponsored placements are mixed into the ranking. They are always flagged isSponsored; set includeSponsored: false to drop them for a clean organic ranking.

How it works

No API key, no login, no browser. The listing arrives server-rendered in a single <script>window.model = {…}</script> assignment (~273 KB) carrying both the 96-field product records and honest pagination metadata.

The schema.org/ItemList JSON-LD on the same page was checked and not used: it covers only 20 items with 4 fields each. This repo's usual stability ladder puts JSON-LD first, and here it is simply worse — checked rather than assumed.

WAF and TLS

None. But one profile-shaped surprise worth knowing: safari18_0 answers 403 on the search surface while chrome124, chrome131, chrome136, chrome99_android and firefox133 all return the full 494 KB document. That profile is excluded from the pool rather than left in to surface later as a mystery failure.

Datacenter proxy pinned to Turkey is the default. The pin is a correctness setting first: n11 serves prices, availability and promoted placements for the local market.

Policy

n11.com/robots.txt names no AI crawler, and /arama is allowed for User-agent: *. Only public product listings are read — no login, no user data, no personal profiles.