Every merchant on one DIY product — price, live stock and delivery window, as JSON

One merchant's offer for a product. ManoMano is a marketplace, so the same reference is listed by many merchants; a search row carries the merchant that ManoMano is showing for it, with that merchant's price, name and country. To see the competition, call product/offers with the product_id: it returns every competing merchant, sorted cheapest first, each with its own price with and without VAT, live stock count, eco-participation, country and delivery window in days. On one Bosch drill that was 15 merchants across 5 countries on 2026-09-23.

Pass model_id from the search row to product/detail. A ManoMano article can group several variants (up to 7 on the products sampled) - a 800 mm and a 1.6 m guide rail share one article, with different EANs and different prices. model_id identifies exactly one variant, and product/detail refuses to return a different one. If you pass only article_id, you get the article's default variant and variants_count tells you how many exist.

Both. price is the selling price with VAT as the storefront shows it, and price_ex_vat is the same offer without VAT, because ManoMano publishes both. reference_price is the struck-through comparison price and is never returned as the current price; it is null when the storefront shows none, so the API never invents a discount. The source's own discount figure comes back as discount_percent and the one computed from the two prices as discount_percent_computed, separately, so a disagreement is visible rather than hidden. Where an eco-participation applies it is already a component of the price: measured across 9 French appliances, price and price_ex_vat differ by exactly the VAT rate, leaving no room for the fee on top.

Yes, and it is normalised so it joins. Measured across five categories on 50-row samples, EAN was present on 49/50 in Outillage, 50/50 in Jardin, 49/50 in Electricite, 45/50 in Plomberie and 43/50 in Salle de bain. The storefront publishes the same code in two different forms on two surfaces, a zero-padded 14-digit GTIN in search and a 13-digit EAN on the product page; the API returns the 13-digit form on both, so a search row and a detail record join on ean without any cleaning at your end.

product/detail returns them as a named table: 25 to 31 attributes on the products sampled, each with an id, a name, its values, its unit and whether it is numeric or textual, for example Tension electrique 18 V or Poids 1.8 kg. Search rows carry the same attributes as numeric ids to stay compact; search/filters publishes the id-to-name table with units for any query, and you can pass those ids straight back into search as attributes, for example 84:Sans fil, which narrowed a 227,697-result query to 10,438 on 2026-09-23.

Yes, and it is worth checking rather than assuming. Measured on 2026-09-23 with the same query: France returned 50,259 results, Germany 23,029, Italy 22,562, Spain 18,842 and the United Kingdom 8,858, with different merchants, different prices and different product titles. The UK storefront prices in GBP, the other four in EUR, verified against each storefront's own product payload. Merchants sell across borders, so seller.country is its own field: a UK listing can be shipped by a merchant registered in China and a Spanish listing by a French one.

Each one was measured unfiltered against filtered in the same run, and all thirteen changed the total. Against 227,697 unfiltered results for one query: brand cut it to 2,943, seller to 384, category to 11,200, a 50-100 price band to 22,603, minimum rating 4 to 5,714, free delivery to 194,188, pickup-point delivery to 11,710, ManoMano Fulfilment to 706, eco-responsible to 900, on-promotion to 25,604, and a technical attribute to 10,438. A brand that does not exist returns 0 rather than silently ignoring the filter. Filters the source accepts and then ignores are not exposed.

category/browse returns 56 server-rendered rows a page and the storefront caps a category at 6,000 products, 100 pages: page 100 serves rows and page 101 is reported as past the last page, not as an empty success. The response returns total_estimated alongside total_reachable so the cap is visible - one category reported 11,202 matches but only 6,000 reachable. Paid placements are left out by default and counted in sponsored_dropped (8 of 56 on the first page of one category); set include_sponsored to get them back, each flagged is_sponsored.

ManoMano API is a ReefAPI endpoint group for europe's diy marketplace in 5 countries: every merchant's price, live stock and delivery window, plus ean and the technical specs. It returns live JSON through POST requests under /manomano/v1.

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

No login to ManoMano 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.

ManoMano actions currently cost 1-2 credits per successful call. Failed or blocked calls are free. All APIs draw from one credit pool.

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