One barcode in, momox's whole condition ladder out — a price and a real unit count for every grade

It is a dealer. momox SE buys used media in bulk, grades every copy by hand and sells it from its own warehouses, so there is exactly one seller per market and one price per condition grade. Nothing in a response is another trader's offer, there is no buy-box, and because the only seller is a company there is no personal data on this source at all.

Yes, and it is the fastest route in: momox keys its own catalogue on the barcode. An ISBN-13 or a full 13-digit EAN returns exactly one product — measured 1 row each for a book ISBN, a film EAN, a game EAN and a software EAN. ISBN-10 works too and is converted for you, which matters because the storefront's own search answers a bare ISBN-10 with zero hits. One warning worth repeating: an EAN must keep its leading zeros. The storefront answers 711719833857 with nothing and 0711719833857 with the right product, so the API pads a 12-digit code for you and verifies the check digit before it asks.

The catalogue is far bigger than the total the storefront reports. Its own uncapped category counts on the German store on 2026-10-08 were 6,973,323 books, 497,483 music, 270,513 film, 39,186 games and 7,133 software, and 9,371,214 across the five condition grades. But its result total saturates at exactly 10,000 — five materially different queries all reported 10,000 and 334 pages — so the API publishes total_is_capped when it hits that ceiling and hands you the uncapped facet counts as catalogue_count_hint rather than repeating a number it knows is wrong.

A real unit count, per grade and in total, and the two agreed on every product measured. Examples from live calls: 3,349 Good plus 470 Acceptable copies of one Harry Potter hardback (3,819 total), 105 of a DVD, 13 of a Nintendo Switch game, 21 of a PlayStation title. You also get in_stock booleans derived from those counts, and a flag for whether the per-grade counts add up to the total momox publishes.

Only the ones measured to change the result against an unfiltered call in the same run, on two different queries. Working: condition (several at once — 653 New plus 1,264 Good returned as 1,820 together), physical format (2,378 unfiltered became 754 paperback, 207 DVD, 96 Audio CD), a price band (50 in the 1-2 EUR band, 558 at 20 EUR and above), the FSK age rating, a contributor shelf, an include-unavailable switch (2,378 became 5,759), and five sort orders verified to reorder the rows. Three things the storefront accepts and then ignores — a language filter, a category passed as a query parameter, and a misspelt sort word — are deliberately not offered, and anything else it drops is reported in meta.warnings.

No, and the API refuses rather than fake it. The storefront silently drops the keyword on every category shelf except the whole catalogue: the film shelf returned the same 28 rows and the same total with the keyword, without it, and with a nonsense keyword, and its own parameter echo showed the keyword had been thrown away. So query and category are mutually exclusive here, with the measurement in the error message. Narrow a keyword with format, condition or a price band instead — those all work — or browse the shelf without a keyword.

Two: medimops.de for Germany and momox-shop.fr for France, both in EUR, both the same platform. The store changes the price, the stock and the category ids, not only the language — measured on the same ISBN in the same minute, 4.51 EUR with 3,819 copies on the German store and 4.49 EUR with 3,818 on the French one. Category ids are not transferable (Bücher is 186606, Livres is 8), which is what the categories action is for: it returns 300 German and 228 French shelves with every id, name, depth and parent. The German store also publishes an FSK age-rating filter that the French one does not have, and asking for it on France is rejected rather than silently ignored.

Three things, said plainly. momoxfashion.com, the group's second-hand clothing store, is a different platform with a different catalogue and is not read here. momox.de, where momox publishes what it PAYS for a used ISBN, is not here either — this API is the selling side. And there is no per-copy detail: momox publishes a grade for the copy you will receive, not a photo or a note about that individual item. Paging also stops where the source stops: page size is variable (29, 28, 30, 29, 30, 27, 26 and 8 rows were measured on consecutive pages of one query) and one page past the end the storefront quietly broadens the query, so the API reports last_page, page_rows and an exact_match flag instead of letting a loop run off the end.

momox / medimops API is a ReefAPI endpoint group for europe's biggest second-hand media dealer as json: look a book up by its isbn or a disc by its ean and get momox's whole condition ladder — a price and a real unit count for new, like new, very good, good and acceptable — across 9.4 million live listings on medimops.de and momox-shop.fr. It returns live JSON through POST requests under /momox/v1.

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

No login to momox / medimops 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.

momox / medimops actions currently cost 1-3 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 momox actions with the same key, credit pool and JSON envelope used by normal REST requests.