Every Greek shop's price for one product, in one call

As many as Skroutz lists, in a single upstream request - there is no pagination on the merchant table. Measured on 2026-09-06: 49 shops on a De'Longhi descaler (382 KB, 1.5 s), 48 on an iPhone 17 Pro Max (361 KB, 1.4 s), 43 on a New Balance 530, 36 on a Ulefone Armor 28 Ultra, 14 on the Teka GFH 73 reference product (102 KB, 0.96 s). A single-merchant product is 21 KB and 0.63 s. Median across the 13 products was 231 KB and 1,425 ms. That makes offers the CHEAPEST of the three actions on bytes - a product page is 429 KB median - which is unusual for a price-comparison site and is the reason it is priced the same as the other two rather than above them.

No. It is the offer Skroutz features, and it was above the cheapest merchant offer on 7 of the 13 verification products - once by 10 percent, at rank 16 of 29. On a listing card the same rule holds: a card reading 120,00 EUR sat on a product whose cheapest merchant offer was 108,99 EUR. If you need a floor, call product/offers and read price_min there; that action returns the real band and its cheapest and most expensive rows. product/detail returns price_min, price_max and offer_count as explicit nulls so you cannot mistake the featured price for a band.

Because that card is a variant family and Skroutz printed a RANGE instead of a price - "285,86 EUR - 1.999,00 EUR" for a TV sold in 43 to 98 inches. Measured on the television category page: 33 of 48 cards were in that state. A first-number-wins parser would return 33 confident wrong prices there, so the engine returns price as null, puts the two endpoints in price_from and price_to, sets variant_family to true, and always returns price_display with exactly the string Skroutz printed. Between price and price_to, every row on every page measured was accounted for: 48/48 TVs, 52/52 perfumes, 57/57 laptops, 55/55 washing machines.

Yes, and this one is a trap in the raw page. Each merchant row carries a data attribute with a pre-coupon price, and on a row with a running coupon that number is wrong: the rendered price was 759,05 EUR, the struck-through price 799,00 EUR and the coupon 39,95 EUR. Reading the attribute would ship a price 39.95 EUR too high while returning ok:true. The engine reads the rendered final price instead and returns price_before_discount and discount alongside it. 3 of the 332 measured offer rows were in that state - rare, and exactly the rows a customer would notice.

Because Skroutz answers broad keywords with one of its own pages - "laptop" becomes its laptops category, "samsung" becomes its Samsung brand page - and it drops the page number on the way, so asking for page 2 of a redirected keyword returns page 1 again. The engine detects that and re-requests from the resolved URL, so paging works either way; it costs one upstream request when Skroutz stays on its search route and two when it redirects. The response tells you which happened: search_mode reads keyword or resolved, with resolved_title and resolved_url. A keyword can also resolve onto an editorial article, which carries no product cards at all - that comes back as an honest count of 0 with the article URL, not as an error.

Twice, independently. A second extractor written as raw regex over each merchant block, sharing no code with the engine's parser, agreed on 332 of 332 offer rows. The only two rows where the two disagreed at all were merchant NAMES, and there the engine was the more correct one - it decodes HTML entities, so it returns "Woman's Fashion" and "Web & IT" where the naive extractor returns the escaped text. A recursive scan of every string in all 26 verification payloads found 0 raw HTML tags and 0 HTML entities.

There is never a zero. 252 of 332 measured offers carried a shop rating; the other 80 came from shops Skroutz has genuinely not rated, and those return null for both the rating and the rating count, never 0.0. The invariant was checked directly - 0 rows had a null rating sitting next to a non-null rating count. Note also that a shop's rating and a product's rating are two different numbers and are returned in two different places: on one verification product the item had a review_count of 6 while its single seller had a rating_count of 3.

A rating scale, first of all: there is no maximum-rating value anywhere in the page or its structured data, so rating_scale is null on every action rather than an assumed 5. What you get instead is the per-star histogram itself, so you can read the buckets first-hand. Also absent: a price band or shop count on the product page (both live on product/offers), a link into the merchant's own site - the only link Skroutz exposes is its own click-through - an exact stock number when the shop declares a band like "5+ pieces" (the text is returned, the number stays null), a per-size price, since Skroutz prices the product rather than the size, and a shop rating for an unrated shop. Skroutz also has no stable search page size; it returns 48 to 60 rows depending on the page it resolved to, so read count.

Skroutz API is a ReefAPI endpoint group for greek price comparison: every greek shop's price for one product. It returns live JSON through POST requests under /skroutz/v1.

Yes. ReefAPI starts with 1,000 free credits, no card required. Skroutz calls use the same shared credit balance as every other ReefAPI engine.

No login to Skroutz is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.

The page example is captured from a live search call, and production requests fetch live data through ReefAPI rather than a static sample.

Skroutz actions currently cost 1 credit per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.

Yes. Connect ReefAPI once through MCP and your assistant can call skroutz actions with the same key, credit pool and JSON envelope used by normal REST requests.