I Tried Wiring Public APIs to AI Agents and Got Lost on the National Law Website

I want to build an environment where AI agents can put public data to work freely.

The idea: an external AI agent connects to my homepage cursorai.co.kr, requests the data it needs, and my server calls the government agency's API on its behalf and hands back the result.

In plain terms, I'm building a shared data counter that AI agents can use.

I plan to run it for free. I get and manage the API keys, and other agents go through my server to use the data.

But once I actually started, it turned out to be harder than I expected.

First attempt: the weather API

I started with the Korea Meteorological Administration.

I found the API on the Public Data Portal, applied for it with a developer account, and even wrote up the purpose. The daily call limit is 10,000, which looked fine for a service just getting off the ground.

I figured I could use the real-time and short-term forecast endpoints so agents could pull weather data.

I'd already set up safeguards on the server — hourly caching, per-minute request limits. I wasn't planning to just wire the API straight through; I wanted to run it with call volume under control.

Then a worry occurred to me.

Even if wiring up one public API isn't hard, what happens to the server when I scale this to 10 or 20 services?

Do I have to serialize everything, or allow concurrent requests but cap them?

My thinking settled on this: managing actual request volume and concurrency matters more than the number of APIs itself.

Second attempt: the law API

Next up: the Ministry of Government Legislation.

I figured that if an AI agent could pull actual statute data when asked a legal question, that would be genuinely useful.

I went to the National Law Information Center's shared-use site and applied for an OPEN API.

The application screen said auto-approval, and my application list showed an approved status.

"Oh, this'll be quick, then."

Thinking that was my mistake.

I got the approval, but I couldn't figure out where I was supposed to actually call the API.

Digging through the site, I found a menu called Developer Lab.

Statute Korean URL, sample source code, statute list support, IP access history, error self-diagnosis...

I started clicking through one by one.

I thought it was an API — turns out it's a download service

I found a menu called Statute List Support.

By the name alone it looked like the place to pull statute data via API. Going in, it turned out to be a feature for downloading lists as HTML, Excel, XML, or CSV.

Oh — this isn't an API call screen, it's a service for downloading the statute list as a file.

So I ended up back where I started.

I need to check the sample source code menu and figure out how the actual request URL and credentials are meant to be used.

I applied, and now I'm hunting for instructions on how to use it.

If you're a developer, this might feel familiar. It looks like one button press and you're done, but once you're in, there are several menus and you have to figure out which one holds the feature you're after.

We've reached the era where AI writes the code, but that doesn't mean the human's job has disappeared.

If anything, the process of deciding what to build, checking the official docs, and verifying that it actually works has become more important.

What I want to build is not a list of API links

My goal isn't a site that just collects public API links.

I want an environment where an external AI agent discovers my homepage, figures out what data is available, and can actually request it and get results back.

I plan to start with weather and connect statutes, statistics, tourism information, and so on one at a time.

Of course, each API has its own terms of use, so I need to check whether relaying it to external agents is allowed. Just because an API is free doesn't mean you can necessarily re-provide it to other users.

I'll start within what the server can handle and scale up gradually as I watch usage.

I got a little lost on the law site today, but at least I can now tell which menu is the download feature and where I need to look for the calling instructions.

Nothing's finished yet.

Still, I'm building it by hitting each thing head-on, one at a time.

The application was approved — but I still haven't managed to call the API.

That's today's dev log. hahaha