**Source (original):** Ministry of Land, Infrastructure and Transport (MOLIT), published through Korea’s open data portal data.go.kr. Free, “\uc774\uc6a9\ud5c8\ub77d\ubc94\uc704 \uc81c\ud55c \uc5c6\uc74c” (no restriction on use, commercial included), auto-approved API key, 10,000 calls\/day on a dev account.<\/p>\n
– Apartment sales: https:\/\/www.data.go.kr\/data\/15126469\/openapi.do<\/a><\/p>\n – Apartment rent (jeonse\/wolse): https:\/\/www.data.go.kr\/data\/15126474\/openapi.do<\/a><\/p>\n – Officetel, commercial\/office buildings, row houses, land etc. are separate endpoints under the same publisher.<\/p>\n **What’s in it.** Every registered transaction, by district (5-digit LAWD_CD) and month. Sales give price, exclusive area, floor, build year, road address, and a cancellation flag. Leases give deposit, monthly rent, previous deposit\/rent, contract term, whether the renewal right was exercised. Unit\/door numbers are withheld for privacy, so there’s no PII in it. History goes back years; my checks were on 2026.<\/p>\n **Gotchas** (all of these cost me time):<\/p>\n XML only, no JSON.<\/p>\n<\/li>\n Two generations of endpoints coexist. Legacy ones return Korean tag names (`\uac70\ub798\uae08\uc561`, `\uc804\uc6a9\uba74\uc801`), the `*Dev` ones return English (`dealAmount`, `excluUseAr`). Same data, different keys.<\/p>\n<\/li>\n Tag casing is inconsistent *between* endpoints: sales give `roadNm` \/ `roadNmBonbun`, rent gives `roadnm` \/ `roadnmbonbun`. Bit me directly. (Sales is also internally inconsistent: `roadNmCd` but `roadNmbCd`.)<\/p>\n<\/li>\n Amounts are in \ub9cc\uc6d0 (10,000 KRW) as comma-formatted strings, sometimes padded \u2014 `’38,670’` means 386,700,000 KRW. Parse, don’t cast.<\/p>\n<\/li>\n The commercial-property endpoint has no exclusive-area field at all, only building area. Don’t assume the schema generalizes.<\/p>\n<\/li>\n Service keys come in encoded and decoded flavors; double-encoding the encoded one silently returns `SERVICE_KEY_IS_NOT_REGISTERED_ERROR`, which reads like an auth problem but isn’t.<\/p>\n<\/li>\n You must file a separate usage application per API, not once per account.<\/p>\n<\/li>\n<\/ol>\n **The gotcha worth the post: don’t pool \uc2e0\uaddc (new) and \uac31\uc2e0 (renewal) lease contracts.**<\/p>\n Renewals are capped at +5% by Korea’s lease cap law, so they sit below market. The API labels them in `contractType`, and if you ignore that label, you’re publishing a number that’s a blend of market prices and legally-capped ones.<\/p>\n Seoul, all 25 districts, July 2026, apartment leases (n = 16,520; 8,310 new \/ 7,896 renewal \/ 314 unlabeled):<\/p>\n | | all contracts | new only |<\/p>\n |—|—|—|<\/p>\n | jeonse share | 50.2% | **43.9%** |<\/p>\n | median jeonse deposit | 570M KRW | **598M KRW** |<\/p>\n | median monthly rent (wolse) | 730k KRW | **800k KRW** |<\/p>\n So “Seoul is half jeonse” is an artifact of pooling \u2014 renewals skew jeonse-heavy because that’s who exercises the renewal right. New-contract share is 44% and falling.<\/p>\n New contracts only, by district, July 2026:<\/p>\n | District | n | jeonse % | median jeonse deposit | median wolse rent | median wolse deposit |<\/p>\n |—|—|—|—|—|—|<\/p>\n | Gangnam | 575 | 41% | 900M | 1.60M | 200M |<\/p>\n | Seocho | 521 | 47% | 850M | 1.71M | 281M |<\/p>\n | Gwangjin | 153 | 38% | 775M | 0.77M | 138M |<\/p>\n | Songpa | 649 | 53% | 770M | 1.50M | 240M |<\/p>\n | Yongsan | 198 | 36% | 750M | 1.55M | 173M |<\/p>\n | Dongjak | 254 | 47% | 750M | 1.42M | 200M |<\/p>\n | Seongdong | 285 | 52% | 710M | 1.95M | 150M |<\/p>\n | Jung | 145 | 37% | 700M | 1.10M | 50M |<\/p>\n | Mapo | 385 | 46% | 690M | 1.60M | 100M |<\/p>\n | Seongbuk | 265 | 45% | 650M | 0.80M | 112M |<\/p>\n | Seodaemun | 246 | 48% | 650M | 0.90M | 100M |<\/p>\n | Yeongdeungpo | 395 | 41% | 630M | 0.70M | 129M |<\/p>\n | Jongno | 94 | 29% | 600M | 0.60M | 50M |<\/p>\n | Gangdong | 523 | 38% | 600M | 0.60M | 101M |<\/p>\n | Yangcheon | 387 | 56% | 550M | 0.60M | 99M |<\/p>\n | Gwanak | 292 | 32% | 545M | 0.70M | 71M |<\/p>\n | Gangseo | 414 | 50% | 480M | 0.70M | 100M |<\/p>\n | Jungnang | 365 | 20% | 460M | 0.44M | 94M |<\/p>\n | Eunpyeong | 395 | 50% | 450M | 0.50M | 102M |<\/p>\n | Dongdaemun | 457 | 36% | 450M | 0.54M | 88M |<\/p>\n | Guro | 297 | 43% | 438M | 0.60M | 58M |<\/p>\n | Geumcheon | 129 | 35% | 380M | 0.55M | 60M |<\/p>\n | Dobong | 197 | 55% | 370M | 0.75M | 50M |<\/p>\n | Nowon | 579 | 49% | 340M | 0.80M | 40M |<\/p>\n | Gangbuk | 110 | 46% | 314M | 0.76M | 30M |<\/p>\n | **Seoul** | **8,310** | **44%** | **598M** | **0.80M** | **100M** |<\/p>\n All figures are medians in KRW, straight from the API, no adjustment. Jeonse is a deposit-only lease (no monthly rent); wolse is deposit + monthly rent, so the two deposit columns aren’t comparable.<\/p>\n **Disclosure \u2014 I built a free wrapper.** Getting from the raw XML to the table above is annoying enough that I published four Apify actors that normalize it: English field names, integer KRW instead of \ub9cc\uc6d0 strings, per-m\u00b2\/per-pyeong unit price, ISO dates, an `isJeonse` flag, unknown tags passed through rather than dropped. They’re free and need no API key of your own.<\/p>\n – https:\/\/apify.com\/ootssu\/korea-apartment-transaction-prices<\/a><\/p>\n – https:\/\/apify.com\/ootssu\/korea-apartment-rent-prices<\/a><\/p>\n – https:\/\/apify.com\/ootssu\/korea-officetel-prices<\/a><\/p>\n – https:\/\/apify.com\/ootssu\/korea-commercial-property-prices<\/a><\/p>\n The source of truth is MOLIT, not me \u2014 if you’d rather hit data.go.kr<\/a> yourself, the links up top are all you need, and the gotcha list should save you the afternoon it cost me.<\/p>\n<\/div>\n submitted by \/u\/porche911_kr <\/a> \n
[link]<\/a><\/span> [comments]<\/a><\/span><\/p>
