DEV Community: Yoon

The data nobody sells: why I started taking a daily snapshot of 211,243 companies

Yoon — Thu, 01 Oct 2026 00:14:57 +0000

Korea's National Tax Service runs a clean public API for business registration status. Give it a 10-digit number, get back whether the company is active, suspended or closed. It's free, it's fast, it's accurate.

It also has no memory.

Ask it today and you learn the company is closed. Ask what it was last month and there's no answer, because that question isn't in the API. There's no as_of parameter, no history endpoint, no changelog. The present tense is the only tense available.

That gap turned out to be the most interesting thing I've found while building an API for AI agents, so I did the obvious thing: I started writing down what I saw, every day.

What I built

A scheduled job, running once a day, that asks for the current status of every company in a fixed list and stores the answer. Then it diffs today against yesterday and writes a separate file containing only what changed.

Three days in, the numbers look like this:

Date Observations Changes recorded
Day 1 211,243 — (first run, everything is new)
Day 2 211,243 70
Day 3 211,243 94

The daily snapshot is about 42 MB. The changes file is 1.7 MB. That ratio is the whole point: 99.2% of what I record is confirmation that nothing happened, and the remaining 0.8% is the product.

Here's one change, as stored:

json
{"business_number":"...","field":"status","previous":"active","current":"closed",
"previous_seen_at":"2026-09-29T00:05:14Z","detected_at":"2026-09-30T00:05:14Z"}

A company that was operating when I looked on the 29th had closed by the 30th. I can't prove when it actually closed — only when I observed each state. So that's what I store: not "this company closed on the 29th", but "it was active when I looked, and closed when I looked again." Those are different claims, and for anything that might end up in a compliance report, the difference matters.

Why this is worth doing

Three reasons, in increasing order of how much I care.

One: it can't be bought. The upstream has no history. Neither does anyone else's wrapper around it. If a competitor decides tomorrow that company status history is valuable, their history starts tomorrow. Mine starts today. That gap only widens, and no amount of funding closes it.

Two: it changes the shape of the business. A status lookup is a one-shot transaction — the agent asks, pays two cents, leaves, and may never return. A watchlist is a standing relationship: register 100 suppliers, and every day I check them and tell you only what moved. Small, recurring, and from my side it runs on infrastructure that's already doing the work.

Three: change is the signal, not state. "This company is closed" is a fact. "This company suspended operations three months ago and resumed last week" is an inference about risk, and it's the kind of thing a procurement system actually wants to know. You cannot derive the second from any number of present-tense lookups. You can only accumulate it.

The things that nearly broke it

The job that ran nothing and exited 0. I wrote about this one in the last post: an entry-point guard that compared hand-built file URLs, worked on Windows, silently failed on Linux. The container started, did nothing, exited clean, and the scheduler showed green. If I'd trusted the schedule instead of running it manually first, I'd have "collected" a week of nothing.

Day one proves nothing. On the first run, every record is new, so the diff path never executes. The output looked perfect and told me nothing about whether the comparison logic worked. I only got real validation on day two, when 70 changes appeared and I could check that the previous values, current values and both timestamps were all populated. If you build something that compares today to yesterday, you don't have a working system until the day after you ship it.

Scope discipline is a security feature. The obvious way to decide which companies to track is to watch what users look up. I deliberately didn't. The corpus is built only from public registries — the procurement vendor list and the debarment list — and I enforced that with a runtime guard and a test, not just a comment, because a comment doesn't stop a future version of me who is in a hurry. Query contents never enter the corpus, which means the dataset contains nothing I learned from a customer.

*The cost
*
Roughly 2,100 upstream calls a day against a limit of 1,000,000. Storage is a few hundred won a month. The job runs in about two and a half minutes. It's the cheapest thing in the entire project and probably the most valuable, because every other part of it could be rebuilt by someone else in a week, and this one can't.

The general version

If you're wrapping a public data source for agents, it's worth asking what the source doesn't answer. Usually there's a tense problem: it tells you what is, not what was, not what changed. That absence is the only part of the data you can own.

Everything else you expose is a thinner version of something the upstream already provides. The history you accumulate is yours, and it starts the day you decide to write things down.

Which is a long way of saying: if you're going to do this, start the clock today rather than when you need it. The data you don't record is the only kind you can never get back.

Three bugs that reported success: what "exit 0" doesn't tell you

Yoon — Mon, 28 Sep 2026 03:28:51 +0000

Last week I wrote about shipping a paid API for AI agents and getting two real calls in a week. The follow-up was supposed to be about fixing the product. It turned into something else, because in the process of fixing it I hit three bugs in a row that had one thing in common:

None of them reported an error. All three looked like success.

That turns out to be the failure mode that costs the most time, and I don't see it discussed much, so here they are.

Bug 1: the government API that answers "zero" instead of "wrong"

I was adding debarment records — public sanctions against companies barred from public procurement — to my business verification API. The endpoint took a parameter called inqryDiv. I passed 1.

It returned HTTP 200 with an empty result set. No error, no warning, no hint. The obvious reading: this company has no sanctions on record.

The correct value was 2. With 1, the API answers a question nobody asked and returns nothing, forever, for every company.

If I'd shipped that, my API would have told users "no sanctions found" for every single company in Korea, with a straight face and a 200 status code. That's not a broken feature. That's a feature that confidently lies.

What saved me: I happened to test against a company I knew was sanctioned. If I'd tested with a random company — which would also have returned zero, correctly — I'd never have caught it.
**
Bug 2: the Cloud Run job that ran nothing and exited 0**

I built a scheduled job to enrich my index with registration numbers. Registered it with Cloud Scheduler. Ran it once manually before trusting the schedule.

Exit code 0. Duration: under a second. Cloud Run console: green check.

Nothing had happened.

The entry point had a guard to detect whether the module was being run directly, and it built the comparison URL by hand:

js
// Works on my machine. Not on Linux.
if (import.meta.url === file:///${process.argv[1]}) { main(); }

On Windows, process.argv[1] looks like C:\path\to\file.js, so prefixing file:/// is right. On Linux it's already /app/dist/job.js, so you get file:////app/dist/job.js — four slashes — which never matches. The guard silently evaluated false, main() never ran, the process exited cleanly, and the platform reported success.

The fix is one line (pathToFileURL(process.argv[1]).href), but that's not the interesting part. The interesting part is that a green checkmark in a scheduler dashboard is not evidence that your code ran. It's evidence that a container started and stopped without crashing. Those are very different claims.

If I had trusted the schedule instead of running it once by hand, I would have seen green checkmarks every morning for a week while the index sat untouched, and I'd have gone looking for the problem in the API, the credentials, the data — anywhere but the one line that decides whether the program starts at all.

Bug 3: the query that returned nothing because of my terminal

With the job fixed, I tested search with Korean company names over curl in Git Bash. Zero results. Every time. English names worked fine.

I was minutes away from digging into the normalization pipeline — Korean text has its own encoding pitfalls, so a bug there was entirely plausible — when I ran the identical query from a local Node script instead. It worked.

The server was fine. Git Bash was mangling the UTF-8 in the URL before it ever left my machine.

This one cost the least time but taught the sharpest lesson: when a test fails, the test environment is a suspect too. I'd been treating my terminal as a neutral observer. It wasn't.

The pattern

Three different layers — a government API, a container platform, a shell — and the same shape each time. Something went wrong, and every signal I had available said things were fine.

What they have in common is that each one answered a different question than the one I was asking.

I asked "does this company have sanctions?" The API answered "here are the results for a query type you didn't intend": zero.
I asked "did my enrichment run?" The platform answered "did the container exit without crashing?": yes.
I asked "does search work?" My terminal answered "does search work when the input is corrupted?": no.

Every layer answered truthfully. None of them answered my question.

What I do differently now

Three rules, written into my project docs so future-me can't argue with them:

Verify against a known-positive, not a random sample. Testing sanctions lookup with a company that has no sanctions proves nothing, because a broken implementation and a correct one give identical output. You need a case where the right answer is not empty.

Exit code 0 is not evidence of work. Check the artifact. Did the file's timestamp change? Did the row count move? Did the summary log print? A scheduler dashboard tells you about the container's lifecycle, not about your program's intent.

Run scheduled jobs manually once, immediately after registering them. The gap between "registered" and "actually working" is where silent failures live for days. Five minutes now versus a week of green checkmarks later.
**
The broader version of this**

I've been building an API whose customers are AI agents rather than people, and this problem gets worse in that context, not better. A human user who gets "no sanctions found" for a company they know is sanctioned will email you. An agent will write it into a report and move on.

Agents don't have the intuition that catches a wrong-but-plausible answer. They can't tell "confidently empty" from "correctly empty." Whatever you return, they'll act on.

Which means for agent-facing APIs, the distinction between empty and broken isn't a nice-to-have in your error handling. It's the product. I ended up encoding it explicitly: a genuine no-match returns 200 with an empty array and a note saying this is a definitive result, not an error; an upstream failure returns 503 with an error code. Same absence of data, two completely different meanings, and the consumer has to be able to tell them apart without guessing.

Three bugs that said "success" taught me that. I'd rather have learned it from someone else's post, which is why I'm writing this one.

I optimized an API for AI agents instead of humans. Here's what one week of data looked like.

Yoon — Wed, 23 Sep 2026 00:43:57 +0000

Yoon

Sep 16

I made Korean government data agent-payable with MCP and x402 — here's what actually happened

#ai #mcp #webdev #cryptocurrency

5 min read

Two weeks ago I put a paid MCP server online: Korean business verification, priced per call in USDC over x402. I wrote up the build here. This is the follow-up nobody writes — the part where you check whether anyone actually showed up.

Short version: 23,980 requests in seven days, and two of them were real.

Here's what I learned from the gap between those two numbers.

The experiment

One hypothesis, one number to falsify it. Hypothesis: if agents can discover a priced API and pay for it autonomously, some of them will. Success bar: 20 real tool calls in the first week after launch. I wrote that number down before launching, which turned out to be the single most useful thing I did.

Metric	Day 0	Week 1
Requests (7 days)	~8,700	23,980
Real external tool calls	0	2
Third-party payments	0	0

Requests nearly tripled. Real usage went from zero to two. Every payment in my receiving wallet is still one I made myself.

Breaking the 41 logged tool calls down by origin: 7 were my own indexing payments, 32 were crawlers requesting the literal path template from the discovery catalog (/v1/business/:brno/status — they call the placeholder, not a real number), and 2 were actual external calls. Both on the same day, hours apart, then nothing for six days.

So: missed the bar by a factor of ten.

The traffic wasn't fake. It just wasn't people.

After getting listed in the x402 Bazaar, a new class of visitor showed up: kkj-x402-trust-index (its user agent says it verifies Bazaar-listed x402 resources), allow402-quote, x402-observer, x402-census-probe, plus the usual liveness bots that announce "never invokes tools" in their UA string.

An ecosystem of watchers has grown up around agent payments, and it found me within days. There's something genuinely encouraging in that: the infrastructure works. Discovery works. Listings propagate. Scanners verify you. What hasn't arrived is the buyer.

The thing I'd fix first if I started over

Here's the mistake I only saw when I stopped looking at request counts and started reading connection logs.

69 handshakes. 17 curl calls. 39 from python-requests. People connected. Almost none of them executed a tool.

My server takes a 10-digit Korean business registration number as input. But if you're an agent outside Korea evaluating a supplier, what you have is a name — "Hanil Trading Co., Ltd" — not a registration number. That number lives on invoices and contracts, which means by the time you can use my API, you already have a relationship with the company.

I built a tool that requires you to already have the thing you came looking for.

That's not a discovery problem or a pricing problem. It's the shape of the product. No amount of catalog optimization helps when the first input field is one your user can't fill in.

Three things I'd tell anyone shipping a priced API for agents

Start from the agent's task, not your data. "Look up a registration number" is a data endpoint. "Decide whether to transact with this supplier" is a task. Agents arrive with tasks. If your endpoint sits in the middle of one, you have to own the entrance too, or someone else's tool will.

A free tier is a discovery liability, not just a pricing decision. The Bazaar validator checks that an unpaid request returns 402. My friendly free tier returned a cheerful 200, so the catalog concluded the resource wasn't payable and skipped it entirely. Default-paid with opt-in free (?free=1) fixed it — and closed the hole where rotating IPs got unlimited free calls.

Catalogs index routes, not servers, and only after a payment settles on that route. Each of my three endpoints stayed invisible until I'd paid for that specific one myself. Worse, all three had near-identical descriptions, so every query surfaced the same route. Rewriting them by intent — status for "is this company still operating", batch for "screen this supplier list", verify for "KYB identity match" — made queries that never mention Korea start returning the right one. Highest-leverage hour I spent all month.

Where the next two weeks go

Not into more distribution. Two things:

An entrance. Resolve a company name to a registration number, so an agent can start from what it actually has. Harder than it sounds — name matching is fuzzy, so the honest design returns ranked candidates with evidence, not one confident answer.
Signals worth paying for. Debarment records, sanction history, status changes over time. One call that answers "should I transact with this company" instead of "does this number exist".

Then I measure again the same way: number written down first, honest count after.

If you're building something agent-facing and have run your own numbers, I'd like to compare. My suspicion is that a lot of us are shipping data endpoints into a market that only buys finished tasks — and that the distance between 23,980 and 2 is mostly the shape of what we built, not the size of the market.

I made Korean government data agent-payable with MCP and x402 — here's what actually happened

Yoon — Wed, 16 Sep 2026 05:04:40 +0000

TL;DR: I built a remote MCP server that lets any AI agent verify Korean businesses using official National Tax Service data — and charge for it per call in USDC via x402. It works end-to-end: here's the first on-chain payment — an agent hit a 402, paid $0.02, and got real government data back, no human in the loop. It's now listed on the x402 Bazaar, Coinbase's discovery catalog for agent-payable APIs, where it currently ranks at the top for "korean business registration verification" — agents find it by searching, not by reading docs. Along the way I learned that directory listings get you 1,250 bot requests a day, that a free tier can silently disqualify you from payment marketplaces, and a few other things nobody tells you.

Why Korean business data

If you're a procurement or compliance agent outside Korea and you need to answer "is this Korean supplier a real, active company?", you're stuck. The official data exists — Korea's National Tax Service (NTS) runs a free public API — but it sits behind a Korean-language portal, phone-verification signup, and API key issuance that an autonomous agent simply cannot do. An agent can't pass Korean SMS verification. It can't read the docs. It gives up or hallucinates.

That gap is the product: Korea Business Verify (KBV) — one URL, no signup, no API key. Ask it about a 10-digit business registration number and get back active/suspended/closed status, tax type, and KYB identity matching, in clean English JSON, straight from NTS. Up to 100 companies in a single batch call.

Server: https://kbv-server-f7vfitmlkq-du.a.run.app/mcp (Streamable HTTP)
Source: https://github.com/Wonderfulian/kbv-server (MIT)
Free: 10 calls/day. Beyond that: $0.02 per status check, $0.05 per identity verification, $0.02/company for batch — paid in USDC on Base via x402.
The stack, briefly

NTS public API → TypeScript + official MCP SDK (+ Express for REST) → Cloud Run (scale-to-zero, so idle cost ≈ $0) → x402 v2 (@x402/express, @x402/core, @x402/evm) → Coinbase CDP facilitator → USDC on Base. The server never touches a private key — it only knows the receiving address. Settlement verification is the facilitator's job.

One paid call, end to end. The agent never talks to a human — it discovers the price, signs the payment, and gets the data.

Total cash spent to build, deploy, and verify all of this: about $3 (one exchange transfer fee plus test payments to myself).

What nobody tells you (the honest part)

Directory traffic is a mirage. After listing on the official MCP Registry, Glama, and Smithery, my server started receiving ~1,250 requests a day. Exciting! Except a User-Agent breakdown showed nearly all of it was health-check and security-scanner bots — some literally announce "never invokes tools" in their UA string. Actual external tool calls in the first week: effectively zero. If you're building an MCP server: request count is not a popularity metric. Count tools/call, nothing else.
Your free tier can disqualify you from payment marketplaces. x402 has a discovery marketplace (the Bazaar) where paying agents find priced resources. Its validator checks that an unpaid request returns HTTP 402. My server had a friendly free tier — 10 calls/day per IP — so the validator got a free 200 and concluded the resource wasn't payable. The free tier also meant anyone rotating IPs could scrape indefinitely. Fix: REST now returns 402 by default, and the free tier became opt-in via ?free=1. Default-paid, intentionally-free turns out to be the right default for the agent economy.
Everything is three months newer than the docs. The MCP registry rejected my first two publishes because the server.json schema had changed weeks earlier. x402 moved to v2 (new headers, new packages) while most tutorials still show v1. Cloud Run's URL took four hours to propagate on a fresh project. None of these are hard problems — but every one of them cost hours, and none of them appeared in any guide. Budget for the ecosystem shifting under your feet.
The "receiving crypto without an exchange account" part is easier than expected. I'm in Korea, where Coinbase's retail exchange isn't available. Didn't matter: receiving x402 payments needs only a wallet address. The facilitator handles verification. My keys live in MetaMask, never on the server.
Independent scanners will find you before customers do. Within days, a trust-scoring service (M8ven) had auto-indexed the server, run static analysis (clean: no credential exfiltration, no obfuscation), and emailed me one legitimate fix — my tools were missing the four MCP annotation hints (readOnlyHint etc.), which OpenAI's directory requires. The agent ecosystem is growing an immune system faster than it's growing customers. I claimed the listing and fixed the hints the same day.
Discovery catalogs index routes, not servers — and only after someone pays. The x402 Bazaar only indexed the exact route I had actually settled a payment on. My other two endpoints stayed invisible until I paid for each of them myself. And the indexing happened the instant I paid — but the public listing lagged by days, long enough that I concluded I'd failed when I had actually succeeded. If you're doing this: pay once per route, then wait before you panic.

Where this stands

KBV is brand new — I completed the end-to-end mainnet payment verification just this week, and this post is its public debut. It's discoverable on the x402 Bazaar with full input/output schemas, so a paying agent can find it and call it correctly without any documentation. The x402 buyer pool is real but still early — this is a land-grab phase, not a gold rush. What I have is a verified, monetized, trust-scored piece of infrastructure that cost ~$3 and a few weekends, sitting on a corner (Korean official data, agent-payable, zero-setup) that nobody else occupies yet. When agentic procurement becomes normal, the pipes are already laid.

Try it

Add the URL as a custom connector in Claude or ChatGPT and ask it to verify a Korean business — Samsung Electronics is 124-81-00998 if you need a test number. First 10 calls a day are free (?free=1 on REST). Code, schemas, and pricing are in the repo. I'd genuinely love to hear what breaks.

Built by a solo non-engineer in Seoul with heavy help from Claude (design/review in chat, implementation via Claude Code). Happy to answer anything about MCP monetization, x402 v2, or wrapping government data for agents.