open-apis-korea: a Korean-language directory of public APIs, forked from public-apis

What open-apis-korea actually is, and who it is for

The README opens with a warning that the project is a fork of public-apis, translated and extended for Korean-speaking developers. That single sentence defines the scope. This is not a client library, a proxy or a hosted service. It is a Markdown catalogue of public APIs, organised into roughly fifty categories that run from development and health through games, finance, weather, news, government, geocoding, jobs, vehicles, books, cloud storage, text analysis, environment and currency exchange. Two categories at the end are specific to the Korean market: Naver and Kakao.

The intended reader is a developer building a service for Korean users who needs to know, quickly, whether an API exists, whether it requires authentication, whether it is served over HTTPS and whether it advertises CORS support. Each row answers those four questions. The authentication column uses short tokens such as apiKey, OAuth or X-Mashape-Key, and the HTTPS and CORS columns use circles, crosses and question marks. That question mark is honest: it means the maintainers did not confirm the property, not that the API lacks it.

The homepage points to open-apis.dev, which suggests the README is also rendered somewhere as a browsable site. The repository itself contains .gitattributes, .github/, .travis.yml, README.md, README_EN.md and a build/ directory. The presence of README_EN.md matters: the English list is kept in the same repository rather than only upstream, so a reader who wants to compare the Korean entry against the original wording can do so without leaving the fork.

How the catalogue is structured and what the build directory implies

Every category is a Markdown table with four columns: the API name as a link, a Korean description, the authentication method, and the HTTPS and CORS flags. The tables are long. The development category alone runs from 24 Pull Requests and Agify.io through Bitbucket, Bored, Browshot, CDNJS, Changelogs.md, CountAPI, DigitalOcean Status, DomainDb, Faceplusplus, Genderize.io, GitHub, GitLab, Gitter, HTTP2.Pro and IBM Text to Speech before the excerpt given here ends. That density is the product. You scan a column, not a page.

The .travis.yml file and the build/ directory are the only hint of automation in the repository layout. A continuous integration configuration in a repository that is mostly a README usually means one of two things: the README is generated from a data source and the build checks that the committed README matches, or the build validates links and table formatting. The README does not state which. Anyone planning to contribute a large number of entries should read .github/CONTRIBUTING.md and the contents of build/ before editing README.md by hand, because a generated file will overwrite manual edits on the next run.

The description column is where the fork earns its place. Entries are written in Korean, and the Korean-market categories are additions rather than translations. That is the real difference from upstream public-apis: not the language of the prose, but the presence of Naver and Kakao as first-class sections and the placement of government APIs in a list a Korean developer will actually scan.

Getting the repository and using it for the first time

There is nothing to install into your application. The README gives no package name, no pip command and no npm package, because the project is a repository of documentation. What you install is the repository itself, if you want a local copy to read. The README does not give a clone command, so the only thing to copy is the repository address from the metadata.

Once you have the files locally you have README.md, README_EN.md, .github/, build/, .travis.yml and .gitattributes. The catalogue is a set of Markdown tables, so the way to work with it is to open README.md and follow the category links in the table of contents. The table of contents covers development, health, games and comics, science and maths, transport, finance, weather, news, calendar, data validation, animals, machine learning, documents and productivity, security, video, business, fraud prevention, dictionaries, photos, social, shopping, sports and fitness, anti-malware, cryptocurrency, animation, art and design, open data, open source projects, food and drink, music, people, government, continuous integration, geocoding, jobs, vehicles, books, cloud storage and file sharing, test data, text analysis, tracking, patents, events, environment, currency exchange, URL shorteners, Naver, Kakao and reference material.

A first real use is picking one API and checking whether it fits before writing code. Suppose you need age estimation from a first name. The development table lists Agify.io with no authentication, HTTPS marked as supported and CORS marked as supported. That combination means you can call it from a browser without a key. The table does not give you the endpoint, the rate limit or the response shape. You follow the link in the first column to the provider's own documentation for those. The catalogue tells you the API exists and what it costs you in setup; the provider tells you how to call it.

The same pattern applies to the Korean-specific entries. If you are integrating Naver or Kakao services, the README has dedicated sections for them, and you should treat each row the same way: read the auth column first, because OAuth or apiKey changes your architecture more than anything else in the table.

The limitations you should weigh before depending on it

The repository metadata does not state a licence. That is the first limitation, and it is not cosmetic. A catalogue is a compilation, and compilations can attract their own rights separate from the APIs they describe. The README says the project is a fork of public-apis, but it does not state the upstream licence or how this fork is licensed. If you plan to mirror the tables, embed them in a product or republish them, you have no stated permission to point at. Ask the maintainer.

The second limitation is freshness. Every row is a claim about a third party, and third parties change their authentication model, retire endpoints and move documentation URLs. The HTTPS and CORS columns are the most fragile, because a provider can change either without touching the API surface. A question mark in the CORS column is not a defect, but it does mean the maintainers did not verify it, so you cannot treat a blank as a green light.

The third limitation is the format itself. A Markdown table cannot express rate limits, pricing tiers, deprecation status, data residency or terms of use. For a Korean service, data residency and terms of use are often the questions that decide whether you can use an API at all. The catalogue has no column for them. If your project needs an API that handles personal data, this list is a starting point for a legal and security review, not a substitute for one.

Finally, this is the wrong tool if you want a typed client. There is no Python package, no generated SDK and no schema. The primary language of the repository is listed as Python, which reflects the tooling in build/ rather than anything you import. If you want to call an API from code, you will write the client yourself.

open-apis-korea compared with public-apis and with API discovery tools

The obvious alternative is public-apis, the upstream repository this one forks. The difference is not only language. public-apis is the larger, more frequently referenced list, and it is the place to look if you want the widest set of international entries and the longest history of contributions. open-apis-korea trades that breadth for locality: it adds Naver and Kakao sections and a set of Korean government and open-data entries, and it rewrites descriptions in Korean so that a Korean-speaking developer can scan a table without translating each row mentally. If your service is not aimed at Korean users and your team does not read Korean, upstream is the better source.

A different kind of alternative is an API discovery or documentation tool that indexes OpenAPI and Swagger specifications, such as the APIs.guru entry that appears in this very list. The approach is opposite. A curated Markdown list is human-edited and opinionated: someone decided the API was worth a row and wrote a one-line description. A specification index is machine-collected and precise: it gives you a schema, an endpoint list and versioning, but only for APIs that publish a specification. Many of the Korean entries in this repository, particularly government APIs, are unlikely to publish an OpenAPI document, which is exactly why a curated list is useful for them.

A third comparison is to a general search. Searching for a Korean weather API returns blog posts, Stack Overflow answers and vendor marketing. The catalogue's value is that the four columns are consistent across hundreds of rows, so you can filter by auth method or CORS support in a way that search results do not let you do.

Maintenance, contribution cost and the licence question

The repository is not archived, and the last push was on 2026-07-28. That is recent enough that the project is being touched, but a push date tells you nothing about whether a specific row is still accurate. For a directory, the meaningful maintenance question is not how often the repository changes; it is how quickly a broken entry is corrected after someone reports it. The README points contributors to .github/CONTRIBUTING.md, which is where the process for adding or fixing an entry is described. Read it before opening a pull request, and check build/ as well, because a generated README will reject hand-formatted rows.

Upgrade cost is close to zero in the software sense. There is no version to pin and no dependency to break. If you vendor a copy of the tables into your own documentation, the cost is the cost of re-syncing when entries change, and the cost of re-verifying the entries you actually rely on. That second cost is the real one, and it is proportional to how many APIs you use, not to how large the list is.

On licensing, the repository metadata does not give a licence identifier, and the README does not discuss one. The README does state that the project is a fork of public-apis, which means the upstream terms are relevant to whatever this fork inherits. This is a factual gap, not a legal opinion, and the practical step is to ask the maintainer in an issue before you redistribute the catalogue in any form. Using the list to find an API and then reading that API's own terms is a different activity and does not depend on this repository's licence.

Editorial conclusion

Adopt open-apis-korea if you are building a Korean-language service and want one table that already lists Naver, Kakao and government APIs alongside the international entries, and if you are willing to open the linked documentation for each API yourself. Do not adopt it as a runtime dependency: nothing here is installed into your application, and the repository states no licence, so redistributing the catalogue is a question you have to settle with the maintainer before you ship it. Verify three things first: whether the licence question has an answer, whether the build/ directory generates the README or only checks it, and whether the entries you plan to depend on are still reachable, since a directory entry is a link and not a guarantee.

Frequently asked questions

Official sources

1. dl0312/open-apis-korea on GitHub
2. Issues
3. Project website
4. README