Vinted API: ReefAPI vs the Apify Vinted Smart Scraper

$0.67–$1.50 / 1,000 credits on monthly billing, or $0.33–$0.75 / 1,000 credits paid yearly (−50%). Credits roll over and never expire, and every engine draws from the same balance. Failed calls are free except verified SHEIN NOT_FOUND on product/detail and price (4 credits). Credits are not requests: measured across 1,124 catalog actions on 2026-08-25, 67% cost one credit, 18% cost two and 5% cost three.

Result rows are only charged when they reach the Dataset, so a scrape that finds nothing pays no row fee. The Actor Start event is charged regardless, and the premium workflow events are charged per workflow run rather than per useful row. ReefAPI does not charge for failed or blocked calls at all — measured during the September 2026 outage, 353 consecutive NOT_FOUND responses on catalog_search metered 0 credits.

The gate is a cookie, not a header — and the cookie is a 12-hour anonymous token anyone's browser gets

Isolated A/B/C on one IP with only the cookie varying. With the minted cookie and full headers: 200, 20 items. With no cookie and the same full headers: 401, code 100, invalid_authentication_token. With the cookie and nothing but accept: application/json: 200, 20 items. So headers do not decide it. The token's own JWT puts exp minus iat at 43,200 seconds, scope public, no login, and it is not IP-bound: minted on one exit and replayed on another it still returned items. A durability burst ran 30 of 30 catalog calls on one token while rotating the exit IP every five calls, all 200. This is why the engine is priced as cheap datacenter work and not as a browser farm.

Vinted's own search window stops at 960 results per query — for everyone

Against us, and it is the first thing a harvest plan hits. Both a free-text 'nike' search and a plain category browse reported total_entries capped at 960, with total_pages capped to match, and asking for a page past the cap returned HTTP 400. per_page is effectively capped at 96 (ask for 100, get 96). 960 is the accessible window, not the true inventory count. Getting more means splitting the query by facet — brand, size, price band — and no Vinted API or scraper can do better, because the ceiling is Vinted's.

The filters are real filters, and the detail response does not carry a seller

All four sort orders behave: price_low_to_high returned prices of 1.00, 1.00, 1.00, 1.00 while price_high_to_low on the same query returned 13,444.44, 11,111.00, 10,000.00 and 10,000.00. A price_from=10 price_to=20 band came back 17.0, 18.9, 19.99, 20.0, 10.0 — honoured. brand_ids=[14] returned rows whose brand really was that brand, so the id filter is a filter and not a text match. Two things to know: brand_search is fuzzy upstream, so searching 'nike' put a different brand first in the list, and item_detail carries no seller block at all — seller ids have to come from a catalog_search row's seller.id. Reference lists on one site returned 26 countries, 44 size groups, 29 colours, 6 conditions and 9 top-level categories.

The site you ask does not reliably decide the currency you get back

Against us, and it will silently corrupt a price comparison. One item, one afternoon, two rounds, five national sites: the Polish site quoted it in zloty, the Swedish site in krona, the British site in sterling — and the French and German sites handed back the seller's own Danish krone, unconverted. So the currency is not simply the site's own currency. Read the currency code on every row and never infer it from the tld you asked for. The item ids themselves are global, not per country: the same numeric id turned up in the Polish and Swedish result sets in one run, which is the opposite of how OLX behaves.

There are two prices on every search row, and item detail drops one of them

Against us. A search row carries the item price, the buyer-protection fee and the total the buyer actually pays, as three separate fields — compare one seller's item price against another's total and you will see a gap that does not exist. The item_detail response leaves the buyer-protection total out entirely, so if you need it, take it from the search row rather than re-fetching the item. Speed is uneven too: in one run the British site answered in about a second and the French site took most of thirty seconds for the same query.

Vinted deleted the search endpoint and our busiest engine was down about 25 hours

The worst thing that happened to this engine, with the numbers. Vinted removed /api/v2/catalog/items at roughly 12:00 UTC on 2026-09-14. From then until the fix deployed at 13:24 UTC on 2026-09-15, catalog_search returned NOT_FOUND 353 times on the affected account and succeeded 12 times in the minutes before the break. Those 353 failures metered 0 credits. Every other Vinted action — item_detail, seller, seller_items, seller_feedback, similar, brand_search, autocomplete, categories — kept working; catalog_filters did not. After the fix, the customer's own recorded failing parameters replayed clean at 0.6 and 1.0 seconds on a warm container. This is what 'what breaks' looks like on a site with no public API: not a wall, a removed route.

Since that rewrite, a search row carries one photo — the rest are only in item detail

Against us, and a regression a real customer noticed the next day. Vinted's replacement search endpoint returns a single photo per card and there is no parameter that re-enables the rest; the old endpoints are gone. The full set is still in item_detail — measured live on the same listings, 5 and 6 photos with ids and urls. So a gallery now costs one catalog_search plus one item_detail per item, which is 2 credits more per item. Brand, size and condition on search rows also changed: they are no longer a dedicated Vinted field, so we fill them only when two sources agree and leave them empty when they do not. Empty, never invented.