South Korea's biggest marketplace as JSON, with the two limits stated up front

Coupang is a single-market marketplace, so there is no country parameter and no currency parameter, because there is nothing to choose between. Every price comes back as a whole-number integer of Korean won with no decimals, currency is KRW on every row, and price_display carries Coupang's own formatted string beside the number so you never have to parse one to get the other. Live on 2026-09-07 across 231 rows in four different queries, price, price_display and currency were filled on 231 of 231. The keyword itself can be Korean or English: Coupang's own index does the matching, and an English brand term returns Korean-titled Korean listings. What comes back is Korean either way, and it is passed through verbatim rather than machine-translated into something that reads more tidily and means something else.

Coupang does not serve its product page to unauthenticated callers, and that was settled by measurement rather than assumed, so the product action answers a different way: it asks Coupang's own index for the id and returns SEARCH-GRADE fields. You DO get the title, the price as a number in won, the list price and the discount, the currency, whether it is in stock, the rating and the review count, one thumbnail, the shipping terms, the promised delivery date, and the item and vendor-item ids. You do NOT get the product description, the specification table, an image gallery beyond that one thumbnail, the seller or vendor name, the option and variant attribute list, the stock quantity, the category path, or any review text. Those are not fields dropped in parsing and no parameter, key or plan turns them on. If your product needs the description or the spec table, Coupang is not a source you can build it on, and it is better to read that here than to discover it in production.

Coupang lists each sellable variant - the 160-count box, the 210-count box, the 400-count box - as its OWN row at its own price under the SAME product id. Counted on real pages: a coffee search returned 60 rows with 45 distinct product ids and 59 distinct item ids; perfume 60 rows and 49 product ids; shampoo 60 rows and 45; and live on 2026-09-07 a wireless-earphone search returned 55 rows carrying only 48 distinct product ids. The prices genuinely differ - one coffee product's items sit at 4,010, 5,700, 5,990, 6,250, 6,270 and 8,550 won and upward - while the rating and the review count are shared across all of them. item_id is the unique key. Because of that the product action returns EVERY item under the id in items[], names the one Coupang ranks first as item, and publishes price_range{min,max,currency} rather than picking one number and calling it the price. Called live on 2026-09-07, id 9034631075 returned 4 items from 1,369,910 to 1,430,000 won and a coffee id returned 52 items from 4,010 to 168,500.

Coupang's own pagination is broken in two different directions and neither has a workaround. Asking for page 2 returns a 200 carrying zero rows. Asking for an offset of 60 returns a full page that overlaps page 1 on 57 of its 60 rows, which is page 1 handed back silently rather than an error. Asking for a larger page size returns exactly 60 rows regardless. So no page, offset or page_size parameter is offered at all: a parameter a source accepts and ignores is worse than one that is not there, and offering one here would have quietly given every caller duplicate data. The response carries page_limit_reached so you can see when you are against the ceiling. The way to reach more of Coupang is to ask narrower questions - a tighter keyword, a price band, the rocket-delivery filter - and run them as several searches.

A keyword Coupang cannot match is answered with 60 unrelated recommendations, not with an empty page, and Coupang publishes no flag anywhere in that response admitting it: measured on 15 nonsense keywords, every single one came back with 60 rows. So this endpoint derives its own boolean, possible_no_match, and it is labelled in the response and in the docs as ours and not Coupang's, because a derived signal presented as the source's own is a lie waiting to be believed. It was validated on 22 real and 15 nonsense queries: 36 of 37 correct, with 0 false positives on the 22 real ones, so it never wrongly tells you your good results are junk. The single miss was a nonsense word Coupang fuzzy-matched to a real bubblegum brand. Two simpler signals were tried and rejected on measurement first: title relevance fails because a real search for airpods returns titles reading 에어팟 and scores zero, and response size fails because a genuinely narrow REAL query is smaller than a junk page.

Coupang publishes no seller identity whatsoever on the surface open to us - not a name, not a store, not even an id. That was checked by looking rather than assumed: the seller-name, vendor-name, store-name and shop-name keys occur zero times in the payload and a deep walk of full records found no seller path of any kind. seller is therefore an explicit null rather than an object of empty strings, and re-checked live on 2026-09-07 it was null on 231 of 231 search rows and 52 of 52 items of a product lookup. rating_scale is null for a different and equally deliberate reason: Coupang publishes no maximum anywhere, so the scale is not inferred from it and not inferred from the 3.5, 4, 4.5 and 5 values that happen to arrive. What Coupang does publish is the rating as a percentage, passed through as rating_ratio. brand is null on almost everything, because it exists on 1 row in 420 - Coupang's R.LUX luxury listings - and it is passed through where it is there rather than reconstructed from the title.

Live on 2026-09-07 across 231 rows in four queries: the item id, the product id, the vendor item id, the title, the url, the price, the formatted price, the currency, the in-stock flag, the promised delivery date, the cash-reward line, the sponsored flag and the thumbnail were each filled on 231 of 231. Across the three genuine queries in that set, the rating and review count were filled on 162 of 171 rows and the shipping terms on 148 of 171; the engine's own build run measured those at 99.0 and 94.0 percent over 420 rows in 7 categories, and the difference is which keywords you happen to ask. The list price and the discount percentage arrive on 160 of 231, because Coupang publishes them only where it is actually showing a discount. Four of these are Korean-market fields you will not find exposed elsewhere: the rocket-delivery filter, the promised delivery date in Coupang's own wording, the cash-reward line, and the sponsored-placement flag on every row, which is what lets you count Coupang's ad slots rather than mistake them for organic results.

The published price was compared with the structured data Coupang embeds in its own page, for the same query, fetched in the same minute, matched row by row: 278 of 279 agree, 99.6 percent, and the single disagreement was a refrigerator whose price moved between the two calls. The detail that matters is HOW they were matched. Matched on the item id they agree 99.6 percent; matched on the PRODUCT id the same data shows 37 apparent disagreements, which is not a parse error but the variant problem above - the two sources were being asked about two different pack sizes of the same product. That is the mistake this engine exists to stop you making, and it is the reason item_id is the key everywhere in the response.

Both actions are flat-rated at one credit and each is a single upstream request. The engine's verification run was 72 calls over 35.6 minutes with 0 failures, a run in which a 200 carrying zero rows counted as a failure rather than a success. The filters were held to a bar most are not: the same query run four times overlaps ITSELF on 54 to 56 rows out of 60, so anything sharing more than about 45 rows with an unfiltered control has not been proved to do anything. Against that floor, sorting by newest overlaps 3 of 60, most expensive first 5, cheapest first 12, best-selling 31, a price band 19 with 55 of 59 rows inside it, and rocket delivery 38 with the rows carrying Coupang's own 로켓 and 와우 strings. A minimum-rating filter was tried and NOT shipped, because it stayed inside the noise floor and a request for 4.5 and above returned a row below 4.5 - an unprovable filter that was also wrong.

Public marketplace listings only, and there is nothing here about a person to begin with: Coupang publishes no seller, no vendor and no store identity on this surface, so no name, profile or contact detail can appear in a response even if Coupang starts filling those fields. There is no Coupang account and no login of yours anywhere in the path, so there is no account of yours that can be rate-limited or suspended. What you send is a ReefAPI key; what comes back is the product data Coupang shows anyone who opens its search page.