DEV Community: KDatafactory

Google Maps scraping works everywhere — except Korea. Here's the Naver Place equivalent.

KDatafactory — Sun, 19 Jul 2026 23:55:17 +0000

If you've ever built a lead-gen pipeline, a local-SEO tool, or any "pull every business in this city" scraper, you've probably leaned on Google Maps / the Places API. It works in almost every country on earth.

Then a client asks for Korea, and the whole stack quietly falls apart.

I'm a Korean developer, and I want to explain why Korea is a black hole for every Western location tool — and show you the ~10-line equivalent that actually works here.

Why Google Maps is broken in Korea (it's not your code)

This trips up almost everyone the first time. You run your normal Google Places pipeline against Seoul and get back thin, wrong, or empty data. You assume you misconfigured something. You didn't.

South Korea has a decades-old law that bars exporting high-precision national map data to servers outside the country. Google has never been allowed to host Korea's detailed map data abroad, so Google Maps in Korea is permanently crippled: no real driving directions, sparse POI coverage, missing hours, missing phone numbers, missing reviews. Locals know this and simply don't use it.

What they use instead is Naver — Korea's dominant search engine — and specifically Naver Place (네이버 플레이스), which is the real "Google Maps of Korea." Every café, clinic, restaurant, gym, and repair shop in the country lives there with hours, phone, rating, and reviews. Kakao Map is the #2.

So the practical reality for anyone outside Korea:

Google Maps / Places API → the tool the rest of your product uses → useless in Korea.
Naver Place → where the actual data is → Korean-only UI, no public API, aggressive anti-bot.

That gap is why "Korea coverage" is a line item Western data vendors quietly skip.

What actually stops you

It's not just "translate the UI." Three things stack up:

No clean public API. Naver's map endpoints are internal, undocumented, and change without notice.
Korean-native everything. Query semantics, address formats (도로명주소 vs 지번), category taxonomy — all Korean-first. You can't guess the right query as a non-Korean speaker.
Datacenter IPs get gated fast. Hit it from an AWS range and you'll eat rate-limits and CAPTCHAs within a few hundred requests, especially once you paginate into per-place reviews. You need Korean residential IPs and sane session handling.

None of these are hard individually. Together they're why most people give up and mark Korea "not supported."

The ~10-line version that works

I ended up packaging this as a pay-per-result Apify actor so I never have to babysit the anti-bot layer again. Here's the whole thing — no local browser, no proxy setup, just an API call:

import requests

TOKEN = "YOUR_APIFY_TOKEN"
ACTOR = "naver-place-scraper"

resp = requests.post(
    f"https://api.apify.com/v2/acts/{ACTOR}/run-sync-get-dataset-items?token={TOKEN}",
    json={
        "searchQuery": "강남역 카페",   # "Gangnam Station cafe"
        "maxPlaces": 20,
        "includeReviews": True,
        "maxReviewsPerPlace": 10,
    },
)

for place in resp.json():
    print(place["name"], "—", place["rating"], f'({place["reviewCount"]} reviews)')

The query is the one part you can't fake as a non-Korean speaker. The trick locals use: location + category. 강남역 카페 (Gangnam Station + café), 홍대 맛집 (Hongdae + good-eats), 제주 흑돼지 (Jeju + black pork). That combo is what makes Naver return a tight, relevant list instead of noise.

The output

Everything comes back as clean, English-keyed JSON — no Korean field names to map, no HTML to parse:

{
  "name": "Starbucks Gangnam-daero",
  "category": "Cafe",
  "phone": "1522-3232",
  "roadAddress": "390 Gangnam-daero, Gangnam-gu, Seoul",
  "businessHours": "07:00 - 22:00",
  "rating": 4.3,
  "reviewCount": 1842,
  "coordinates": { "lat": 37.4979, "lng": 127.0276 },
  "reviews": [
    {
      "rating": 5,
      "date": "2026-06-30",
      "text": "Clean, quiet on weekday mornings, fast wifi.",
      "keywords": ["clean", "good for work", "friendly staff"]
    }
  ]
}

Name, category, phone, both address formats, hours, rating, review count, coordinates, and paginated per-place reviews with the sentiment keywords Naver attaches. That's the exact shape a lead-gen enrichment step, a local-SEO audit, or a "should we enter this neighborhood" market study needs — and it's the shape Google's API can't give you inside Korea.

Reviewer identities are never collected — just the review text, rating, date, and keywords.

Where this is useful

Lead generation — every local business in a category/area, with phone + address, for outbound.
Local SEO / listings — audit and monitor how businesses show up on the platform Koreans actually search.
Market-entry research — density, ratings, and review volume by neighborhood before you commit.
Review mining — pull the Korean-language review corpus for a brand or category and run sentiment on it.

The honest build-in-public part

This is one of ~30 Korean-platform scrapers I've been building solo — the sites that are big inside Korea but that nobody outside can crawl: Naver Place, Olive Young (K-beauty rankings), Encar (used cars — huge for exporters), KREAM (sneaker resale), and so on. Same thesis every time: Korean-native in → clean English JSON out. The language wall and the anti-bot wall are exactly what make these worth packaging instead of leaving as a DIY afternoon.

I'd genuinely like input from people who scrape for a living:

For lead-gen and local-SEO use cases, is per-place review pagination worth the extra requests, or is the summary (rating + count) enough for most of you?
On Korean hosts specifically, what's your go-to for session rotation — sticky sessions with retry, or per-request rotation? I've had far better luck with sticky+retry and I'm curious if that matches your experience.

If you want to try the Naver Place one, it's here: Naver Place Scraper on Apify. First runs are on the free tier, so you can see the JSON before deciding anything.

And if there's a Korean site you've hit this exact wall on, tell me — that's how I pick what to build next.

the silent wrong-ranking bug

KDatafactory — Wed, 15 Jul 2026 01:01:51 +0000

A customer told me my scraper's #1 product was wrong. They were right — and the bug was nastier than a crash.

I run a small catalogue of scrapers for Korean e-commerce and content platforms. Last week a customer using my Olive Young (a huge Korean beauty retailer) best-seller scraper sent me a short, polite message:

"The ranking looks off. Your #1 is a probiotics supplement, but the real #1 on the site is a MEDIHEAL mask sheet."

She was completely right. And the reason why is the kind of bug I now think about a lot.

It wasn't down. It wasn't empty. It was plausibly wrong.

My nightly health-checks were all green. Every run succeeded, returned 100 items, and every field was populated — real product names, real prices, real images. If you glanced at the output it looked perfect.

The problem: the order was wrong, and the products were the wrong set. My scraper's "#1 best-seller" was a diet-probiotics capsule. The site's actual #1 was a face mask.

Here's what happened. Olive Young serves ranking data from two different places:

product-ranking-service.oliveyoung.com/v1/pages/ranking/sales/products — an internal "sales ranking" microservice.
global.oliveyoung.com/display/product/best-seller/order-best — the endpoint the site's own "Best" page actually renders.

My scraper called the first one. The site shows the second one. Both return real, valid-looking products in a real order — they're just different boards. So the scraper produced data that passed every automated check and was still wrong to any human who'd looked at the actual page.

The scary part: it's a whole class of bug

That one report made me stop and audit my whole catalogue against the live sites — not "does it return data" but "does the top-N match what a real user sees right now."

I found the same shape more than once. The common trigger was innocent-looking:

// looks harmless
searchParams: { 'category-id': '' }   // "" = give me the overall ranking, right?

Except the site had quietly changed so that an empty/absent parameter no longer returns the ranking — it returns an unranked default set (sorted by internal product id, every rating 0, half of them sold out). No error. Just a plausible-looking list in the wrong order. A couple of my scrapers were shipping that as "the best-seller ranking."

Other variants I found the same day:

a 6-day-stale cached list served under a no-filter request while the real ranking lived under one specific filter id;
a marketplace where a boolean used flag was inverted (the API's 2 meant new, not 1), so every "new/used" label was backwards;
a webtoon ranking labelled "by rating" that was actually the site's default popularity order.

None of these crashed. None returned zero rows. All of them would sail through a "is it up?" monitor forever.

The lesson I wish I'd internalised earlier

"It runs and returns data" is not "it's correct." For anything ranked, the only real test is:

Fetch what a real user sees on the actual page, and compare your top-N to it — order and identity, not just field presence.

Concretely, what I changed:

Verify against the human-facing view. For each ranking scraper I now diff the top ~5 against the live page the user would look at, not just against "an endpoint that returns products."
Prefer the endpoint the site itself renders. If you find a cleaner-looking internal microservice, double-check it's the same board the page shows. A different host is a red flag.
Add sanity guards, not just presence checks. Fail (loudly) the run if the list is near-monotonic by id, or every rating is 0, or the sold-out share is absurd — those are the fingerprints of a "silent default" response.

The fix for Olive Young itself was small once I understood it — point at /display/product/best-seller/order-best with the params the Best page sends, map the real field names, and now the scraper's #1 is MEDIHEAL, matching the site. (Bonus: the correct endpoint even carries review counts the old one didn't.)

The thing I keep coming back to

The most valuable message I got all month was one sentence from a user pointing out that my #1 was wrong. It didn't just fix one scraper — it exposed a blind spot in how I was validating all of them.

If you scrape ranked data: go look at one of your outputs next to the real page right now. Not the schema. The order.

I maintain a set of Korean-platform scrapers (kdatafactory). If you've hit this "plausibly wrong" class of bug, I'd love to hear how you catch it.

I pulled the 800 newest cars on Korea's #1 used-car site. The map didn't match the market.

KDatafactory — Mon, 13 Jul 2026 07:19:27 +0000

A snapshot from Encar (encar.com), Korea's largest used-car marketplace — 223,000 live listings — pulled 2026-07-13. Public listing data only; no personal or dealer data.

Korea is one of the world's larger used-car export sources, and if you're on the buying end of that trade, the question that matters isn't "what's for sale" — it's "where is listing activity concentrated right now?"

So I took the simplest possible cut: the 800 most-recently-listed cars on Encar, and compared their shape to the whole 223K-listing market. One honesty note up front: "most-recently-listed" includes re-lists and bumped ads, not only cars newly entering the market — so everything below is about listing activity, not proven new supply. The pull took one run of encar-scraper, an Apify actor I maintain that turns Encar's listing feed into clean JSON. If fresh listing activity looked like the standing market, the two should line up.

They didn't.

One province is running 4.5× above its weight

If you work this trade you already know the southeast runs Korea's used-car exports. What I hadn't seen before is that quantified against standing stock. Break the newest 800 down by region and compare each region's share of fresh listings to its share of total inventory:

Region	Share of newest listings	Share of total market	Index
경남 South Gyeongsang	13.0%	2.9%	4.5×
대구 Daegu	16.5%	9.0%	1.8×
인천 Incheon	8.8%	6.1%	1.5×
서울 Seoul	11.3%	10.3%	1.1×
부산 Busan	8.0%	9.7%	0.8×
경기 Gyeonggi	31.4%	42.7%	0.7×

South Gyeongsang holds under 3% of Korea's used-car inventory — but accounted for 13% of the freshest listings in this snapshot. Daegu, next door, ran at nearly double its weight. Together, Daegu + South Gyeongsang = 29.5% of fresh listing activity from 11.9% of the standing stock — a 2.5× concentration.

Meanwhile Gyeonggi — the Seoul-belt province that holds 43% of all inventory — under-indexed (0.7×). The big pool is sitting still; the southeast corner is the one churning.

That corner is also where Korea's export machine lives — Busan port and the Daegu auto-export complex. Two caveats before reading it that way: this is one cross-sectional snapshot, so it can't prove causation, and a handful of high-volume southeastern dealers re-bumping their inventory could account for part of the anomaly. Still, "which region is actively churning listings" is a signal worth watching if you source there — and it's not where a population map would point you.

What's over-represented in fresh listings — and what actually exports

The single most-listed model across the entire fresh feed was the BMW 5-Series (G30) — 19 units, over-indexing at 1.13× (Mercedes, for what it's worth, under-indexed at 0.66× — this is a BMW story, not a "German cars" story). Genesis over-indexed at 1.3×, with 47 units of GV70, GV80, and G80 inside the top 15.

Top fresh models:

BMW 5-Series (G30) — 19
Genesis GV70 — 18
Hyundai Grandeur IG — 18
Kia Ray — 16
Hyundai Avante AD — 15
Genesis GV80 — 15
Kia Carnival (4th gen) — 15

To be clear, this list is a mix: the 5-Series, Genesis SUVs, and Grandeur are export-relevant metal, while the Ray, Avante, and QM6 are domestic-turnover cars that mostly stay home. The signal isn't "everything fresh is export-bound" — it's that the export-relevant segment (premium sedans, Genesis SUVs) is over-represented in fresh listing activity rather than diluted by it. Median fresh asking price: ₩20.9M (~$15,100).

The glut that wasn't in the data

Every few months there's a headline about Korea's used-EV glut flooding the second-hand market. In this snapshot, it didn't show up.

Pure electric cars were 1.9% of the freshest 800 listings — lower than their 3.1% share of standing inventory (a 0.6× index). Whatever is churning through Korea's used market right now, it is overwhelmingly gasoline (60%) and diesel (24%). One snapshot doesn't debunk a narrative, but if EVs were pouring in, this is where it would show — and it didn't.

The age band lines up with export demand

Fresh listings cluster at 2019–2023 model years — 3 to 7 years old. I won't claim intent behind that; a healthy used market naturally churns cars at that age. But it happens to be the band most export destinations' age caps target, which makes the fresh feed unusually usable for sourcing: for buyers, the overlap matters more than the reason.

Reproduce this yourself (~5 minutes, free)

Everything above is one actor run away. On encar-scraper, this input pulls the same fresh-listings sample:

{
  "carType": "all",
  "sort": "newest",
  "maxItems": 800
}

Each record comes back as structured JSON — make, model, year, price_krw, mileage_km, fuel, region, url, image_url — so the region/fuel/price group-bys in this post are a few lines of pandas (or a pivot table; CSV/Excel export works too). Apify's free plan includes $5 of monthly credit, and at $2 per 1,000 results that covers this entire analysis with room to spare — no credit card needed.

Want the second half of the market? Korea's #2 marketplace runs on the same contract: kbchachacha-scraper returns identically-shaped records (~168k more listings), so the two feeds concat into one dataframe cleanly. If your stack talks MCP, both actors also work as AI-agent tools out of the box.

Why I'm posting this

I run a suite of 24 Korean-platform scrapers — Korean sites are largely invisible to Western data tools, and I keep finding stories like this one sitting in plain sight. Everything here is public, non-authenticated listing data: the actor reads Encar's own listing feed and never touches logins, private endpoints, or personal information.

The raw listings aren't the interesting part — anyone can browse those a page at a time. But structured, one afternoon's pull surfaces a regional churn anomaly, a premium-listing skew, and an EV glut that failed to appear — patterns that are hard to see at a glance even if you live in this market.

Next on my list is turning this into a live export-sourcing feed: newest listings by make and region, with destination age-cap eligibility computed per car from model year. If you source cars out of Korea, tell me in the comments which filters would actually matter to you — that's what gets built first.

Method: 800 newest-listed cars (Encar public list API, sort = most-recently-listed) vs whole-market count baselines, 2026-07-13, from a Korean IP. Single cross-sectional snapshot, not a time series — every comparison here is "fresh listings vs standing stock," never "this month vs last." "Fresh" includes re-listed ads. Public listing attributes only; no dealer or personal data collected.

Current Pocamarket median asks by member (Korea's source market, not eBay) — Jul 2026

KDatafactory — Sun, 12 Jul 2026 23:30:32 +0000

Most price references we use (eBay solds, Mercari) are Western resale prices — but cards originate and price-discover in Korea first. I pulled current listings from Pocamarket (포카마켓, Korea's dedicated photocard marketplace, ~477k cards listed) and computed the median asking price per member from the newest listings. Prices converted from KRW at roughly current rates. Sharing in case it helps you price sales/trades:

Group	Member	Listings	Median ask	Range	Wishlist/card
TXT	Yeonjun	11	$5.60	$2.50 – $17.50	1,561
NCT	Mark	8	$4.55	$2.50 – $17.50	402
IVE	Leeseo	15	$4.90	$2.50 – $21.00	796
BOYNEXTDOOR	Taesan	11	$3.50	$2.50 – $66.50	1,358
NCT	Doyoung	9	$3.50	$2.50 – $9.80	1,004
&TEAM	EJ	9	$3.50	$2.50 – $45.50	348
NCT	Yushi	24	$3.00	$2.50 – $9.80	1,442
RIIZE	Anton	10	$2.50	$2.50 – $28.00	290
RIIZE	Wonbin	10	$2.50	$2.50 – $17.50	686
RESCENE	Zena	9	$8.40	$3.50 – $17.50	4

A few things that jumped out:

Demand and price are inverted on the biggest names. NCT Yushi and Doyoung, TXT Yeonjun, BOYNEXTDOOR Taesan all carry huge wishlist counts (1,000–1,560+ per card) but median asks sit at $3–5. That looks like liquidity — lots of supply meeting lots of demand — not weak demand. The cheap median is the floor, not the ceiling.
The range is where the money is. Taesan's median is $3.50 but the top listing is $66.50, and &TEAM EJ runs $2.50 up to $45.50. Medians tell you the common card; the max tells you a chase/grail is in the pool.
Rookie-group economics are flipped. RESCENE Zena has the highest median ($8.40) but almost no wishlist activity (4/card) — thin market, sellers asking high because there's little to compare against. Higher risk if you're buying to flip.
These are asking prices from the newest listings, small samples (8–24 each), so treat them as a reference floor, not sold comps.

If people find this useful I can post an updated table weekly, or break one group down by member/era/card type. Which group should I do next?

The K-pop photocard market has a $2B blind spot: nobody's pricing the Korean source

KDatafactory — Fri, 10 Jul 2026 07:16:54 +0000

If you've ever tried to price a K-pop photocard, you know the pain: the same card is $8 on one app, $45 on a reseller's Depop, and "DM for price" everywhere else. There's a $2B+ collectibles market here with almost no price transparency.

Every price-guide app and reseller tool I've looked at solves this the same way: scrape eBay and Mercari. Which makes sense if you're in the US. But it misses something big — the cards originate and price-discover in Korea first. A card trades on the Korean market for weeks before the Western resale price settles. If you're only watching eBay, you're reading yesterday's news.

So I went to the source.

The source market nobody's scraping
Pocamarket (포카마켓) is Korea's dedicated photocard marketplace — 477,000+ cards listed, organized by group, member, era, and card type (album / fansign / POB / lucky-draw). It's where Korean collectors buy, sell, and set the reference price. For a huge fraction of cards, this is the primary market and eBay is the derivative one.

The interesting part for anyone building tooling: it has a clean public catalog API. No login needed for the listing data.

GET https://pocamarket.com/apis/card/gb/v2/search?q=&page=
Returns per-card, structured: group, member, price, trade type (sale vs. trade), stock, wish count, sales volume, and an image. Everything you need to build a price index — per member, per era, per card type — sourced from where the price actually forms.

What you can do with it
Arbitrage signal. Korean price vs. eBay/Mercary price = the spread. When a card is cheap on Pocamarket and hot on Western resale, that's a sourcing signal before the Western price catches up.
A real price index. sales_volume + wish_count per card let you build a demand-weighted index per member/era — the "StockX for photocards" that collectors keep asking for but nobody's built on source-market data.
Inventory pricing. If you resell, pricing against the origin market instead of guessing beats the DM-for-price economy.
A couple of honest caveats
Prices are the catalog's, not seller identities. The scraper I built collects card + price data only — no seller nicknames, IDs, or profiles. (Both a privacy rule and a legal one — don't scrape people.)
card_type and era need the detail endpoint, not just search. The base catalog gives you the price signal; the per-card detail call adds the metadata.
Sort is fixed to newest-first on the public API — server-side price/popularity sort params are ignored, so you sort client-side.
If you don't want to maintain the scraper
I packaged this as a ready-to-run Apify actor — it handles the pagination, the detail enrichment, and the privacy filtering, priced per result:

https://apify.com/kdatafactory/pocamarket-scraper

(Want the retail side too — K-pop album/goods prices in USD from Ktown4u's global store? There's a matching actor: https://apify.com/kdatafactory/ktown4u-scraper. Origin-market secondary prices + origin-market retail prices is the full picture.)

But the endpoint above is the real unlock. Whether you build it yourself or not, the point stands: if you're pricing K-pop collectibles off Western marketplaces only, you're trading on lagged data. The source market is right there, and it's structured.

Happy to answer questions on the data shape or the index math in the comments.

How I track K-beauty prices for dropshipping without writing a scraper

KDatafactory — Thu, 09 Jul 2026 02:54:15 +0000

If you sell K-beauty, you already know the pain: Olive Young is where the trends start, but the site is in Korean, prices are in won, and the best-seller list reshuffles constantly. Checking it by hand every morning to see what's climbing and what went on sale is a chore — and by the time you notice a product blowing up, everyone else has too.

Here's the automated setup I use to get a daily K-beauty price + ranking feed in English and USD, without maintaining any scraping code.

The idea

Instead of scraping Olive Young yourself (their site actively blocks bots, so this is a maintenance treadmill), you run a hosted scraper on a schedule and pipe the output wherever you want — a spreadsheet, a Slack message, a webhook into your store.

I use the Olive Young Global scraper on Apify because its output is already normalized: English names, USD prices, discount %, rating, review count, and the best-seller rank. Pay-per-result, so a daily pull of the top 100 costs cents.

The setup (about 10 minutes, no code)

1. Grab the best-seller ranking. The scraper's ranking mode returns the current top sellers. Input is just:

{ "mode": "ranking", "maxItems": 100 }

You get back rows like:

rank  name                                       brand      price_usd  sale_usd  rating  reviews
1     Madagascar Centella Hyalu-Cica Sun Serum   SKIN1004   28.00      22.40     4.9     9958
2     Advanced Snail 96 Mucin Power Essence      COSRX      22.00      —         4.8     41k

2. Put it on a schedule. Apify has a built-in scheduler — set it to run every morning. Now you have a daily snapshot with no effort.

3. Send it somewhere you'll actually look. Wire the run's output to Google Sheets (there's a one-click integration) so each day appends a new tab, or to a Slack/Discord webhook. Now you can:

Spot risers — a product jumping from rank 40 to rank 8 overnight is a sourcing signal before it's saturated.
Catch sales — when sale_usd drops on something you resell, you know your margin math changed.
Price competitively — you're pricing against the actual source-market price, in your currency, automatically.

4. (Optional) Track a specific niche. Swap ranking for search mode with a keyword — snail mucin, sunscreen, pdrn — to watch just your category instead of the whole store.

Why USD matters here

Most Korean-data tools hand you won prices and Korean product names, and you're left doing currency conversion and Google Translate before the data is usable. Pulling from Olive Young's global storefront means the numbers already come out in USD with English names — the difference between "data I have to clean" and "data I can paste into a pricing sheet."

The tool

The scraper I use is here: https://apify.com/kdatafactory/oliveyoung-scraper — there's a free tier of platform credit to test it, and the input is exactly what's shown above. If you sell K-fashion instead, the same setup works with the Musinsa one: https://apify.com/kdatafactory/musinsa-scraper

The whole point is to stop checking a Korean website by hand every morning. Set it once, read the feed, source faster than the people still doing it manually. Questions welcome in the comments.

Scraping Korea's biggest stores: the hidden JSON APIs behind Olive Young, Musinsa & Naver

KDatafactory — Wed, 08 Jul 2026 23:48:53 +0000

Korean e-commerce is one of the richest, least-scraped data sources on the web. K-beauty and K-fashion drive billions in global demand, but almost every tutorial you find scrapes Amazon or Shopify — because the Korean platforms sit behind a double wall: the language, and some genuinely annoying anti-bot setups.

I spent a while getting reliable, structured data out of the three that matter most — Olive Young (K-beauty), Musinsa (K-fashion), and Naver Place (local businesses + reviews). Here's what actually worked, the parts that fought back, and the rules I set for myself.

Rule #1: never parse the HTML if the site talks JSON to itself

Every one of these is a JavaScript SPA. If you GET the page and run Cheerio over it, you get a shell. The trick is the same everywhere: open the network tab, reload, and watch what the frontend calls to fill itself in. That call is almost always a clean JSON endpoint — the same data the page renders, minus the parsing pain and minus 90% of the breakage when they reskin the site.

Musinsa was the friendliest. One endpoint powers both category rankings and keyword search:

GET https://api.musinsa.com/api2/dp/v1/plp/goods
    ?gf=A&sortCode=POPULAR&caller=CATEGORY&category=001&page=1&size=60

Swap caller=CATEGORY&category=001 for caller=SEARCH&keyword=<term> and you've got search. The response hands you goodsNo, brandName, normalPrice, finalPrice, saleRate, reviewCount, reviewScore — everything, already structured. No auth. (Their reviewScore is 0–100, so divide by 20 if you want a 0–5 rating.)

Olive Young was two services once I switched to their global storefront (global.oliveyoung.com) — which is actually better for most people, because it returns English product names and USD prices instead of Korean + KRW:

GET  product-ranking-service.oliveyoung.com/v1/pages/ranking/sales/products   # best sellers
POST cbe-external-api.oliveyoung.com/display/v1/search/products/unified-search # search

The domestic site (www.oliveyoung.co.kr) 403'd my datacenter IP immediately; the global one didn't. Worth checking both when a Korean site blocks you — the international storefront is often more permissive.

Naver Place was the stubborn one. The clean data lives in the Apollo cache embedded in the search results HTML:

GET https://search.naver.com/search.naver?where=nexearch&query=강남역 카페

Pull the __APOLLO_STATE__ blob out of the page, and you get PlaceListBusinessesItem nodes with name, category, address, phone, rating, review count — plus a few review snippets linked from each place. The deeper per-place review API (pcmap-api.place.naver.com/graphql) exists, but it CAPTCHA-walls datacenter IPs with an HTTP 405. More on that below.

The parts that fought back

Datacenter IPs get filtered. All three tolerate a light touch from a normal IP but clamp down on cloud ranges fast. The fix is boring: residential proxies (Korea-geo for Naver especially). What matters in code is that a hung proxy tunnel shouldn't take down the whole run — wrap the fetch so a proxy timeout falls back to a direct connection instead of throwing. That one change turned a lot of silent zero-result runs into successful ones.

"Succeeded with 0 results" is a lie you tell yourself. My first Naver cloud run reported success and returned nothing, with no error in the logs — because the code swallowed a proxy timeout and exited cleanly. If a run collects nothing, throw. A paid data tool that silently returns empty is worse than one that fails loudly.

Pagination isn't always real pagination. Naver's search page repeats results after ~15 businesses; true depth requires the GraphQL route (and a residential IP). Know where your easy path ends so you don't ship something that looks paginated but isn't.

Rule #2: public, non-personal data only

This is the line I don't cross, and I'd encourage anyone scraping reviews to hold it too: I never collect reviewer identity. Review objects carry text, rating, date, and keywords — never nicknames, profile URLs, or user IDs. Business phone numbers and addresses are fine (they're public business info); a person's name attached to a review is not. It keeps the data useful for sentiment/market analysis without turning into a privacy problem.

The output that makes it usable

Whatever the source shape, everything normalizes to one flat, snake_case contract:

{
  "source": "oliveyoung",
  "product_id": "GA230518746",
  "name": "SKIN1004 Madagascar Centella Hyalu-Cica Water-Fit Sun Serum",
  "brand": "SKIN1004",
  "price_usd": 28.0,
  "sale_price_usd": 22.4,
  "rating": 4.9,
  "review_count": 9958,
  "rank": 1,
  "url": "https://global.oliveyoung.com/product/detail?prdtNo=GA230518746",
  "scraped_at": "2026-07-07T09:35:33+09:00"
}

Consistent field names and KST timestamps across all three sources mean you can dump them into the same table and diff prices over time without writing per-site glue.

If you'd rather not maintain any of this

I packaged all three as ready-to-run scrapers on the Apify Store — they handle the proxying, the fallbacks, and the JSON normalization, and they're priced per result so you only pay for what you pull:

Olive Young (K-beauty, USD prices): https://apify.com/kdatafactory/oliveyoung-scraper
Musinsa (K-fashion): https://apify.com/kdatafactory/musinsa-scraper
Naver Place (businesses + reviews): https://apify.com/kdatafactory/naver-place-scraper

But honestly, the endpoints above are the whole trick — if you just need a one-off pull, the network tab will get you most of the way. Happy to answer questions on any of the three in the comments.