Naver operates a developer platform, but there is no public API that returns local business profiles with their visitor reviews, reputation aggregates and menus. Its search and map APIs are built for different jobs and are bounded by their own terms and quotas. Reading the public Place pages — which answer plain HTTP requests — is the practical route to that dataset.
Key points
No public API returns business profiles with reviews, reputation aggregates and menus together.
Naver's developer APIs exist for other purposes and carry their own quotas and terms.
The public Place surface answers plain HTTP, which is why no browser or proxy is required.
Without an API contract there is no field guarantee, so a pipeline should assert on the fields it depends on.
The gap that matters is not authentication but geography: Naver's own search response includes out-of-area padding you have to remove.
Naver runs a developer platform, so “is there a Naver API” has a technically positive answer and a practically negative one. The distinction is worth being precise about.
The short answer
There is no public API that returns Korean local business profiles together with their visitor reviews, reputation aggregates and menus. That combination — the thing people actually want — lives on the public Place pages.
What Naver's developer platform covers
Naver publishes developer APIs for search and mapping, aimed at building products on top of Naver rather than at exporting its content. They carry their own keys, quotas and terms, and they are documented mostly in Korean.
The gap, and why it exists
Reviews are the reason. A review corpus with reviewer identities attached is a behavioural dataset about people, and no consumer platform exports that through a public API — the same reason Nextdoor has no read API for its recommendations.
Which is also why this Actor removes those identities entirely: reviews without reviewer identities is the version of this dataset that can exist without becoming a profile of individuals.
The public surface instead
Naver Place answers plain HTTP requests from datacenter IPs. No browser, no login, no proxy — which makes it unusually cheap to read compared with targets like Zonaprop, where a residential proxy is mandatory.
The cost of that convenience is the absence of a contract, and one specific quirk that a documented API would never have shipped: the search response includes out-of-area businesses with no marker. That is the real gap to engineer around.
What that means for your pipeline
Assert on the fields you depend on. There is no versioning, so a field can change shape without notice. Fail loudly rather than writing nulls.
Handle vertical-dependent absence. `visitor_review_score` does not exist for clinics. That is not an outage.
Never quote Naver's match count as inventory. It includes the padding.
Not a public one that returns business profiles together with their visitor reviews, reputation aggregates and menus. Naver's developer APIs serve other purposes and come with their own quotas and terms.
▸Is reading the public pages reliable without an API?
It is stable in the sense that no credential expires — the pages answer plain HTTP from datacenter IPs. What it does not give you is a versioned field contract, so assert on the fields you depend on rather than assuming they persist.
Sources
Every URL below was requested and returned a page on the date shown.
Google Maps coverage in Korea is thin; Naver Place is where the data is. A walkthrough of querying it, and of the padding you have to remove before the results mean anything.
Every Naver review carries a nickname, a stable account id and a link to the reviewer's entire history. None of it is returned, and a test fails the build if it ever is.
Naver's search is Korean-first. The choice of term decides coverage more than any other input, and the region list decides whether the results are where you think they are.
