Rakuma Scraper: Japan Sold Prices & New Listing Alerts

Search Rakuma (fril.jp), the flea-market app run by Rakuten, by Japanese or English keyword and get one row per listing: price in yen, whether it sold, brand and category, with a link. Switch to the sold view for what items really sold for, add a sold-comps summary (median sold price against median asking price), and get a Discord, Slack or Telegram message when a new listing, a newly sold item or a price at or below your target shows up. No login, no cookies, no images, and a search that finds nothing is free.

Who it's for

• Japan-sourcing resellers who buy on Rakuma and Mercari and need to know what a Pokémon card, a bag or a console actually sells for before they bid.
• Price trackers and deal watchers who want a message the moment something under their target price is listed.
• Analysts and AI agents who need Rakuma sold prices as clean JSON, CSV or Excel.

What you get

One row per listing:

• the Rakuma item ID, title, link and price in JPY (not converted);
• a sold flag, so a sold search and an on-sale search read the same;
• the brand and the category as Rakuma shows them (in Japanese), plus the category ID;
• with monitoring on: whether the listing is new, had a price drop, or is unchanged since your last run.

Add the comps summary and each search also gets one extra row: how many sold and on-sale listings were counted, the median price of each, the gap between asking and sold in percent, and how many listings of each kind Rakuma has in total. It uses the same definitions as the Mercari Japan scraper in this portfolio, so the two read alike.

Example: sold prices, comps and a Discord alert

Sold prices for a Pokémon card search, plus the summary, with a message to Discord whenever a new item shows up in the sold feed (schedule it hourly):

{
  "searches": ["ポケモンカード"],
  "mode": "sold",
  "maxItems": 80,
  "includeCompsSummary": true,
  "deltaMode": true,
  "deltaName": "pokemon-sold",
  "notifyUrl": "https://discord.com/api/webhooks/<id>/<token>"
}

The first run remembers what it saw and sends nothing. Every later run returns the listings and posts one message per item that was not there before. Put "alertOn": "price-below" and "alertPriceBelowJpy": 3000 with "mode": "on-sale" to be told about listings at or under ¥3,000 instead.

Fields

Field	What it is
rowType	listing, or summary for the comps row
itemId, url, title	the Rakuma item ID, its link and its title
priceJpy	price in yen; a sold item keeps the price it was listed at
sold	true when Rakuma marks the item SOLD OUT
brand, category, categoryId	as Rakuma shows them; brand is empty on unbranded items
checkedAt	when this run read the page
changeType, previousPriceJpy, priceDropPct, isAlert	monitoring only: baseline, new, price-drop, price-rise or unchanged, and whether the row matches your "Alert on" choice
searchMode, totalAvailable, listingsFetched, truncated	summary row: the mode, how many listings Rakuma has for the search, how many this run read, whether more existed
activeCount, soldCount, activeTotal, soldTotal	summary row: listings counted from each feed, and Rakuma's totals for each
activeMedianPrice, soldMedianPrice, askVsSoldGapPct	summary row: median asking price, median sold price (JPY) and the gap in percent
notifyErrors	why an alert message did not arrive (empty when it did)

Limits

• Yen only, as Rakuma shows them. Nothing is converted.
• No sale date. Rakuma publishes none, so the summary has no "days to sell" and sold rows are ordered by the site's own newest-first order, not by sale date.
• Condition and shipping are not returned. They are not on the search page, only on each item's own page, which this actor does not open.
• No images and no seller details: just the listing facts above.
• Search as the site shows it. Rakuma matches loosely and shows up to 100 pages of 40; this actor returns at most 1,000 listings per search. A keyword Rakuma cannot match at all is reported as not found (free) when it only offers unrelated items.
• Rakuma's search also reads descriptions. A short brand word returns listings whose title never mentions it (in a live check, 51 of 80 sold "supreme" titles did). Add includeKeywords if you want the title to carry the word.
• The summary is a sample. It counts the listings this run read for the chosen mode, plus the 40 newest listings of the other mode. A narrow search with a small maxItems gives a small sample.
• Sold prices include outliers (a listing priced at ¥9,888,000 is a real row). The summary uses medians for that reason.
• Requests are made one per second, through a Japanese residential proxy: Rakuma refuses the shared datacenter proxy.

Monitoring and alerts

Turn on Monitor and the actor keeps one record per watchlist, search and mode in a named store (rakuma-listing-lookup-delta), up to 20,000 listing IDs each, oldest forgotten first. Use the newest-first order and a small maxItems so a new listing is always inside the window. Only return rows that match my alert returns and bills just the alert rows; Seed silently makes the first run return and bill nothing. Alert messages are free, are sent only for rows you were billed for, never carry an image, and a failed message never fails the run. The webhook link is stored encrypted and never appears in logs or results.

How to use

1. In the Apify Console. Open the actor page and click Start — the searches field is already pre-filled with a working example. Results land in the run's dataset as soon as each item is found.
2. Via the API. Call it directly with a POST request — no Console needed once you have an API token:

   curl "https://api.apify.com/v2/acts/accountable_eel~rakuma-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"searches":["ポケモンカード"]}'
   

3. On a schedule. Save this actor as an Apify Task with the input you want, then add a Schedule (hourly, daily, weekly) so it runs on its own — no server of your own required.

Input

{
  "searches": [
    "ポケモンカード"
  ]
}

One search per line: keywords like "ポケモンカード" or "supreme", or paste a fril.jp search link (only its keywords are read; the link is never opened). Rakuma matches loosely, so a keyword it does not know is reported as not found. Accepted formats: ポケモンカード, supreme, https://fril.jp/s?query=nintendo+switch.

Sample output

query	found	status	rowType	itemId	url	title	priceJpy	sold	brand	category	categoryId	checkedAt	changeType	previousPriceJpy	priceDropPct	isAlert	isSummary	searchMode	totalAvailable	listingsFetched	truncated	activeCount	soldCount	activeTotal	soldTotal	activeMedianPrice	soldMedianPrice	askVsSoldGapPct	notifyErrors	rows	scrapedAt
ポケモンカード	true	OK	<row type (listing or summary)>				<price (jpy; for a sold item, its last asking price)>						<change since last run (baseline / new / price-drop / price-rise / unchanged; monitoring only)>	<price at the last run, jpy (monitoring only)>	<price drop since the last run, % (monitoring only)>	<matches your alert (monitoring only)>		<mode of the search (sold or on-sale; summary row)>	<total matching on rakuma (summary row)>	<listings this run fetched (summary row)>	<more results were available (summary row)>	<on-sale listings counted in the summary (summary row)>	<sold listings counted in the summary (summary row)>	<total on-sale listings matching on rakuma (summary row)>	<total sold listings matching on rakuma (summary row)>	<median asking price of the on-sale listings counted, jpy (summary row)>	<median sold price of the sold listings counted, jpy (summary row)>	<asking vs. sold median price gap in % (summary row)>	<alert delivery problems (empty when the alert arrived)>	<all rows of the search in one cell (only when one row per listing is turned off)>	1970-01-01T00:00:00.000Z

A search that finds nothing, a link that is not a keyword, and a block come back as a row with "found": false and a plain-English message, and are never charged.

Pricing

Pay-per-event. A flat per-run fee covers session/proxy warmup; you're billed per item only when data is actually found and returned — see .actor/pay_per_event.json for exact prices. A miss is never charged.

Use it from Clay, n8n, Make, or an AI agent

This actor runs synchronously over plain HTTP — call it directly from a script, a workflow tool, or an AI agent, no Apify Console needed once you have an API token.

curl "https://api.apify.com/v2/acts/accountable_eel~rakuma-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"searches":["ポケモンカード"]}'

n8n. Add an HTTP Request node: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~rakuma-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body Content Type JSON, JSON Body {"searches":["ポケモンカード"]} (swap in an expression from an earlier node for a real value).

Clay. Add an "HTTP API" column: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~rakuma-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body {"searches":["{{search}}"]}, mapping the row's search into the searches array.

MCP. In Claude, Cursor, or any MCP client with the Apify MCP server, ask for "Rakuma Scraper: Japan Sold Prices & New Listing Alerts" — the agent will find and run this actor.

Data and privacy

The actor reads public search pages on fril.jp only, the same pages anyone can open without an account. It stores no personal data: no seller names or IDs, no comments, no images. Rakuma's own terms prohibit scraping; you use this actor at your own risk and are responsible for how you use the data.

FAQ

Is this the sold price or the asking price? Rakuma is fixed price, and a sold listing keeps the price it was listed at, so that is the price the item sold for unless the seller changed it before the sale.

Why did my keyword return nothing? Rakuma ignores words it does not know and shows unrelated items instead. The actor spots that when the result set is small and none of the titles mention your keyword, and returns "not found" without charging.

Can I search in English? Yes, but most titles are Japanese, so a Japanese keyword finds more. Brand names in Latin letters (supreme, nike) work.

Why a residential proxy? The shared datacenter proxy gets an HTTP 403 from the site; a Japanese residential address does not.