Search Rakuten Ichiba and read Japanese marketplace prices as JSON

Rakuten Ichiba, the Japanese marketplace on rakuten.co.jp. Prices come back as integer JPY, item names and review bodies are in Japanese, shop names are Japanese, and images are served from thumbnail.image.rakuten.co.jp and tshop.r10s.jp. Keyword search accepts either Japanese or Latin text: "iphone" reported 8,254,515 matches and "ヘッドホン" reported 601,555.

Because the two surfaces label their identifiers differently and the engine passes each through as found. A search row for the meisei cable returned item_code "10000150", which is the numeric item id; calling item on that same URL returned item_id 10000150 and item_code "246", which is the shop's SKU. The safe join key across actions is the pair shop_code plus manage_number, or the item_url itself, not item_code.

There is no way to tell from the response, because there is no tax field, no tax-inclusive flag and no pre-tax figure in search, item, variants or ranking. item_price is a single integer in JPY, exactly the number the listing shows, and currency is always "JPY". If your accounting needs a split, you have to apply Japanese consumption tax rules yourself against the displayed figure.

Campaign reward points the buyer earns, and they are not a fixed percentage of the price. Measured examples: 20 points on a 258 yen cable, 10 on a 328 yen case, 270 on a 1,980 yen lotion, and one catalogue page spanning 6 to 1,882 points. points appears on search rows but not on the item detail response, so pull it from a listing row when you need it.

The item detail surface does not always carry the aggregate. The seedcoms item returned review_average null alongside review_count 684, and the reviews action returned the same null in its summary while still paging 684 real reviews. Where it is present it can arrive with float artifacts: the meisei item returned 4.429999828338623 for an average that search reported as 4.43. Take the average from a search row and round it.

The reviews action returns 30 per page, with meta.total giving the real count and meta.next_page pointing forward, so 684 reviews is 23 pages. Each row carries rating as an integer 1 to 5, body, reviewer (a Japanese handle ending in さん), helpful_count, posted_at and, usefully, ordered_at, which is the purchase date rather than the review date, so you can measure the gap between buying and reviewing.

page_size reports 45 but the actual page carries a handful more: two different keyword searches returned 49 and 50 rows. Because the next_page cursor advances by the reported page size, consecutive pages can overlap. Deduplicate on item_url when you concatenate pages rather than assuming every row is new.

One row per selectable combination, each with variant_id, selector_values, item_price, currency and merchant_sku_id. A phone case returned 31 variant rows across two selectors, タイプ for model and カラー for color, all at the same 328 yen. Two things to expect: variant_id has no consistent format, mixing plain numbers like "24737" with strings like "r-sku00000009", and image_urls came back empty on every variant, so per-variant photos are not available.

Rakuten Ichiba API is a ReefAPI endpoint group for rakuten ichiba It returns live JSON through POST requests under /rakuten/v1.

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

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

Rakuten Ichiba 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 rakuten actions with the same key, credit pool and JSON envelope used by normal REST requests.