Search Korean businesses on Naver and read their reviews
The Naver Place API returns South Korean local-business data as clean JSON.
7 active endpoints. Every call is 1 credit.
- POST/naver/v1/place/search
- POST/naver/v1/place/search-all
- POST/naver/v1/place/detail
- POST/naver/v1/place/reviews
- POST/naver/v1/place/blog-reviews
- POST/naver/v1/place/resolve
- POST/naver/v1/search/autocomplete
What Naver endpoints does ReefAPI ship?
7 live read endpoints. Read-only data API: no writes, no account actions, no dashboard access on the target site.
Naver API
4 of 7 endpoints, ready to run
Find Korean businesses by name, brand or category — in English or in Korean — and get each one's place id, category, address, review count, coordinates and rating.
{ "ok": true, "meta": { "api": "naver", "endpoint": "place/search", "mode": "live", "latency_ms": 3040.1, "record_count": 10, "cache_hit": false, "completeness_pct": 100 }, "data": { "places": [ { "place_id": "1080585723", "name": "스타벅스 강남교보타워R점", "category": "카페", "address": "강남대로 465 (서초동)", "review_count": 5365, "rating": 4.49, "image_url": "https://ldb-phinf.pstatic.net/20190828_93/1566953601239OT9MQ_PNG/xX7Wv642gXMoTI0DAv0hRymS.png", "longitude": 127.0243352, "latitude": 37.5037107 }, { "place_id": "1086067689", "name": "스타벅스 강남R점", "category": "카페", "address": "강남대로 390 (역삼동)", "review_count": 8258, "rating": 4.51, "image_url": "https://ldb-phinf.pstatic.net/20190828_93/1566953601239OT9MQ_PNG/xX7Wv642gXMoTI0DAv0hRymS.png", "longitude": 127.028439, "latitude": 37.497711 }, { "place_id": "1140751329", "name": "스타벅스 케이스퀘어강남점", "category": "카페", "address": "강남대로94길 10 (역삼동)", "review_count": 118, "rating": 4.67, "image_url": "https://ldb-phinf.pstatic.net/20190828_93/1566953601239OT9MQ_PNG/xX7Wv642gXMoTI0DAv0hRymS.png", "longitude": 127.0282043, "latitude": 37.4991914 } ], "total": 117, "query": "starbucks gangnam" } }
How the Naver API works
Naver is a normal ReefAPI surface — the same four rules that hold for every other engine on the key.
No OAuth app, no request signing, no per-site account. One key covers all 184 engines.
Every route is a POST with a JSON body. Parameters are validated against the published schema before anything is charged.
Credits, not seats. Failed and blocked calls are never charged, and cache hits cost nothing.
One envelope everywhere. meta carries latency_ms, record_count and the endpoint that answered.
Resolve the name, check the flag, then read
A shop name goes in and an id comes out, but the id is not the whole answer — what makes it usable is that the response says what it picked and what it passed over.
{"query": "<the shop name>"}One id, and beside it the name, category, road address and review count of the place it chose, an exact_name_match flag, and the candidates it rejected with the same fields on each.
True means the registered name matched your query character for character and you can go straight on. False means it fell back to a looser match — the branch you wanted is usually sitting in candidates, so pick the id there rather than accepting the top one.
{"place_id": "1086067689", "limit": 20}The star distribution for the whole business, plus the most recent page of visitor reviews. place/detail adds the phone, both address forms and the opening schedule.
Two credits from a shop name to its review shape, with the evidence for the match in the same response. Repeat only the last call to track sentiment; the resolve is needed once per place.
curl -X POST https://api.reefapi.com/naver/v1/place/search \
-H "x-api-key: $REEF_KEY" \
-H "content-type: application/json" \
-d '{"query":"강남 맛집","limit":5}'{
"ok": true,
"data": { … },
"meta": {
"api": "naver",
"endpoint": "place/search",
"mode": "live",
"latency_ms": …,
"record_count": …
},
"error": null
}What a Naver Place row contains, and which address is which
Korea runs two parallel address systems and Naver returns both on every place, which is the field pair most integrations mismatch. These are the fields measured on place/search-all rows for Korean business queries on 2026-08-26. Note what is not there: a search row carries review_count but no rating - the star rating lives on place/detail.
| Field | What it holds | Measured example |
|---|---|---|
| place_id | Naver's numeric place id, as a string; length varies, no prefix | "1943746521" and "33084820" were both live |
| road_address | doro-myeong address - the post-2011 official street-name system | 서울특별시 강남구 강남대로 388 |
| jibun_address | jibeon address - the legacy lot-number system, still used in records | 서울특별시 강남구 역삼동 825-13 |
| short_address | the abbreviated form Naver prints on a card | 서울 강남구 강남대로 388 |
| category / category_id | Korean category name plus its numeric id | 성형외과 with "223246"; 카페,디저트 for cafes |
| review_count | integer, the review count Naver shows for the place | 1408, 2055, 7791 |
| has_booking | boolean - whether the place takes Naver reservations | true / false |
| latitude / longitude | WGS84 decimal degrees, as numbers | 37.4974539 / 127.0284206 |
| distance_km | float, distance from Naver's own map center for the query | Hongdae cafes returned about 11 km on a Hongdae query |
There is no rating field on a search row, so a missing rating is not an unrated business. Also, limit does not raise the row count past 10: queries asking for 20, 30, 40 and 100 all returned exactly 10 places, with data.total also reporting 10.
Did it find the right shop, and how many reviews really come back
Measured across six queries in English and Korean and two Seoul coffee shops, and re-measured after the resolve action was rewritten. Four of these rows go against us and they are the ones worth reading first.
place/resolve no longer hands back a bare number. Asked for the exact Korean name of the Gangnam R branch it returned that branch — id, name, cafe category, road address, 8,258 reviews — with exact_name_match true and the five runners-up it rejected, each with the same fields. Asked the same thing in English it picked a different Gangnam Starbucks and said so: exact_name_match false, with the branch we actually meant sitting first in candidates. Read the flag rather than the id, and the wrong-shop failure becomes visible in the response instead of downstream.
You do not need Korean to use this. 'starbucks gangnam', 'hongdae cafe' and 'myeongdong hotel' all returned the right Korean businesses, with Korean names and addresses in the rows. What thins out is not the language, it is the CATEGORY: place/search leans food and drink, and on three non-food English queries it returned 1, 2 and 10 rows where place/search-all returned 10, 10 and 10 for the same words. Use place/search-all for anything that is not a restaurant or a cafe.
On place/search across six queries the rating field was filled 10 of 10, 7 of 10, 6 of 10, 4 of 10, 4 of 10 and 0 of 1. On place/search-all it was filled 0 of 40 across four queries — that surface carries no rating at all, in exchange for the wider category coverage and a richer address block. The review count was filled every time on both. Size a business by its review count, and take the rating from place/detail, where the whole star distribution comes with it.
A shop reporting 8,258 visitor reviews returned exactly 20 rows whether we asked for 20, 100 or 200, with capped true in the response. A second shop reporting 3,435 did the same. The sort and page-size parameters are accepted and documented as having no effect. What you get instead is the complete star distribution — ten buckets from 0.5 to 5.0 — which is the shape of all of them.
On two shops, 20 rows each, the body was filled 10 of 20 and 9 of 20. A Naver visitor review can be a rating and a photo with nothing written. Read the dates carefully too: they arrive in Korean short form as month, day and weekday, with no year in them.
The blog-review endpoint reports the real total and then tells you what it can reach: on a shop with 1,047 blog posts it returned fetchable_max 113 and handed back 10 rows per call. Those rows are titles and links to Korean blogs and community boards, not review text.
What people build with Naver
The jobs this data is most often used for.
endpoints
credit per call
Local apps call place/search to list Korean businesses by area.
Reputation tools use place/reviews and place/blog-reviews to monitor sentiment.
Lead-gen uses place/search-all to build local business lists.
What Naver data costs
The cheapest call here is 1 credit, so $15/mo (Pro) buys 10,000 of them — $1.50 per 1,000 credits. Credits roll over and never expire, and failed or blocked calls are not charged.
Full pricing →- 1,000 free credits on signup, no card
- One key, all 184 APIs, one credit pool
- Failed and blocked calls are never charged
- Credits roll over and never expire
Call it in two lines
Sign up, get 1,000 credits and one key that works on every engine. Then this is the whole protocol.
curl -X POST https://api.reefapi.com/naver/v1/place/search \
-H "x-api-key: $REEF_KEY" \
-H "content-type: application/json" \
-d '{"query":"강남 맛집","limit":5}'import requests
r = requests.post(
"https://api.reefapi.com/naver/v1/place/search",
headers={"x-api-key": REEF_KEY},
json={
"query": "강남 맛집",
"limit": 5
},
)
print(r.json()["data"])Have a question? We got answers.
The questions people actually ask before wiring up Naver.
Get a free key →Should I call place/search or place/search-all?▾
place/search-all, unless you specifically want restaurants. place/search is the food-oriented surface and carries the richest restaurant fields; place/search-all covers every business type - clinics, cafes, hotels, salons, shops - and is the one that returns place_id, category_id, both addresses and coordinates on a single row. A measured call for 강남 성형외과 (Gangnam plastic surgery) returned five clinics with full profiles.
Why do I get only 10 results when I set limit to 30?▾
Because Naver's place panel serves one page and the engine returns that page. Measured on 2026-08-26: limit 5 returned 5 places, but limit 20, 30, 40 and 100 all returned exactly 10, with data.total also reading 10, across three different queries. Treat 10 as the practical ceiling per query and narrow the query - by district, by neighborhood, by category word - instead of raising limit.
What is a Naver place_id and where else can I use it?▾
It is the numeric id in Naver's own place URLs (map.naver.com/p/entry/place/<id>, place.naver.com/restaurant/<id>), returned as a string. Length is not fixed: 33084820 (8 digits) and 1943746521 (10 digits) appeared in the same result set, so do not validate by length. If all you have is a name, place/resolve turns it into a place_id and shows its work: a measured call on 강남 맛집 returned id 1427134948 with the place's name, category, road address and 9,038 reviews beside it, exact_name_match false because a category phrase is not a shop name, and the six runners-up it passed over. Read exact_name_match before you trust the id.
Why are there two addresses on every place?▾
Korea moved from lot-number addressing (jibeon) to street-name addressing (doro-myeong) in 2011, and both remain in daily use, so Naver carries both. road_address is the official current form and the one to use for mail and geocoding; jibun_address is what older records, land registries and many locals still use. short_address is neither - it is the display abbreviation, with 서울특별시 shortened to 서울. All three describe the same building.
What are place_suggestions?▾
Naver's own related-query list for the search you ran, returned alongside the places as plain strings. A measured call for 강남 성형외과 returned ["강남역성형외과"], and one for 홍대 카페 returned nine, including 홍대 만화카페 and 홍대 고양이카페. Because the row ceiling is 10, these are the practical way to widen coverage: feed each suggestion back as a fresh query.
Do I have to search in Korean?▾
For places, in practice yes. The queries that returned data were Korean text - a business name, or an area plus a business word, like 강남 성형외과 or 홍대 카페 - because that is how the listings themselves are written. Names, categories and addresses all come back in Hangul with no romanized variants, so plan for UTF-8 end to end and for a transliteration step if your users read Latin script. search/autocomplete takes a partial term and returns Naver's own completions - 아이폰 returned 아이폰18, 아이폰17 and 아이폰17프로 - which is the cheapest way to learn the exact wording Korean users type.
What does a TARGET_BLOCKED response mean here?▾
It means Naver answered that attempt with a challenge instead of data, and it comes back with retryable set to true. It is a transient condition rather than a verdict on your parameters, so there is nothing to fix on your side beyond retrying later or spacing calls out. Handle it the way you would a 503: catch the code, back off, and never read the absence of data as "this place does not exist".
How does this engine handle a bad parameter?▾
limit is parsed strictly - a non-numeric limit returns PARSE_ERROR with retryable false rather than being ignored - while query is required and rejected when empty. There is no page parameter on any place action, so pagination is not the shape of this engine. You widen coverage by issuing more queries, not by walking pages.
What is the Naver API?▾
Naver API is a ReefAPI endpoint group for korean business listings, reviews and ratings. It returns live JSON through POST requests under /naver/v1.
Is the Naver API free to try?▾
Yes. ReefAPI starts with 1,000 free credits, no card required. Naver calls use the same shared credit balance as every other ReefAPI engine.
Do I need a Naver login or account?▾
No login to Naver 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.
How fresh is the Naver data?▾
The page example is captured from a live place/search call, and production requests fetch live data through ReefAPI rather than a static sample.
How many credits does the Naver API use?▾
Naver actions currently cost 1 credit per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.
Can I call Naver from an AI assistant or MCP client?▾
Yes. Connect ReefAPI once through MCP and your assistant can call naver actions with the same key, credit pool and JSON envelope used by normal REST requests.
14 Reputation & Reviews APIs on the same key
One key, one credit pool, one response envelope. If you are pulling Naver, you are one call away from the rest of the category — no second contract, no second integration.
Need something this API does not do?
Name the endpoint, the field, or a source we do not carry yet. We ship new APIs every week and you would be first to get the key. Real people read every message and reply the same day.
Try it on your own data before you pay anything
The call above is the real endpoint, not a recording. A free key gives you 1,000 credits, the other 183 APIs, and the same envelope everywhere.
Endpoints, parameters and credit costs on this page are read from the live catalog and cannot drift from what the API accepts. Field notes were captured on 2026-08-28.