Build & Defend Newsletter 24

One email a week - something from which I hope you'll get real value. We talk about things we can build, and how to defend them. That can apply to cybersecurity, physical buildings, digital products, and .... just about anything. It gives me a lot of latitude in what I can write about, but the two concepts are important for progress - as individuals, and as society.

Today's topic is: building data sources. And x402 payments. That is, how to get paid for your data. Yes, you can do that.

A decent data source can become valuable surprisingly fast. Maybe it is a clean feed of prices, alerts, local conditions, company filings, security indicators, property data, or industry research. Or it could be a list of Transformers and all their attributes. Or anything. You collect it, clean it, make it available through an API, and suddenly somebody else's agent wants to call it 10,000 times before lunch. That's great, except why would you want to do all that work and then have to figure out how to charge people for it?

Well, it turns out that's actually easier these days .... there's a new standard, called x402, which is a payment standard that offers a clean answer for certain kinds of machine-to-machine data: charge at the HTTP layer, per request, with a payment requirement that software agents can understand.

No account creation. No invoice chasing. No “contact sales” page for a $0.02 lookup.

Just a useful endpoint, a stated price, and a payment before the response. The best part is that this can all be automated, and the machines do all the work.

What kind of data sources can you build? Just about anything. The trick is that it should ideally have the following characteristics:

So what are some good examples?

You can ask your bot to give you more x402 data build ideas, but this is a good start!

You would also ask the bot to make it so that it should update on a regular basis.

So how do you defend your data source? Well, you charge for it of course! Also, I hope you like micropayments because that's kinda how this works.

Imagine though that thousands of agents in your geography pay USDC 0.01 for resilience data - you could make pennies! But then, when it gets updated (because you build that too) the agents pay for the changes. They also pay for your other data sources, and those changes. You could make whole dollars! If suddenly 10,000 agents from all over the globe need that information, well, then that might add up to some real passive income.

The point though isn't necessarily the amount of money that you'd make, it's that x402 standard. While it sounds like a Lockheed Martin instruction booklet for fighter jets, it's actually a standard on the internet for receiving payment for data that you can use, that Coinbase, Cloudflare, and others came up with to make the internet's last design failure (not including payments by default (from a protocol perspective)) go away. It's available now and you can use it and probably should if you want to make money while doing very little. You don't need a Stripe account, you don't need Shopify, and you don't need a website (just a wallet and a data source) to get going.

Remember, you're defending this data to agents / bots, you're not necessarily selling it to people.

The agent shows up at your API endpoint, gets a 402 "payment required" message from the server, and pays whatever small amount to get the data. It's really kinda that simple. But....

The public endpoint should only see the prepared product. It should never have direct access to upstream API keys, scraping credentials, admin controls, or the machinery that gathers the data. You do still have to defend the data from the cybersecurity aspect of things as well.

Add these basics:

Rate limits before payment handling. Do not let an attacker make your payment verifier do unlimited work.

Strict input validation. Reject garbage early. A domain is a domain, a date is a date, and a query should have a maximum length.

Replay protection and idempotency. A valid payment payload should not buy the same expensive operation repeatedly.

Cache aggressively. If twenty customers ask for the same public data within a minute, calculate it once.

Separate cheap from expensive routes. A lightweight status check should not trigger a large enrichment job.

Log every paid request. Keep request ID, price, payment verification result, response status, source version, and cost to serve.

Set hard spending and usage limits. Your own upstream data vendors will not care that the abusive calls were “technically paid for.”

Use a kill switch. If something starts behaving strangely, be able to disable the paid route without taking down everything else.

There is also a more basic issue: make sure you have the right to resell or redistribute the underlying data. “I can access it” and “I can commercialize it” are very different sentences, as we mentioned above.

If your data comes from public records, licensed APIs, customer-provided information, or your own collection, document that provenance. If it comes from somebody else’s website under terms that prohibit resale, x402 will not make the legal problem disappear. It will merely help you pay for the lawyers you wouldn't have needed if you hadn't done that in the first place.

You'll need the following things:

(Note: Again, I'm not plugging Cloudflare and Coinbase here because they paid me or anything; they're the ones that came up with the standard so they are probably the best to start.)

The x402 project provides SDKs and middleware across TypeScript, Python, and Go. For an initial experiment, build one paid endpoint, use a small fixed price, and test it with a client you control.

Do not launch with ten data products and an elaborate token economy. You are trying to learn whether someone will pay for one clean answer.

Coinbase.com
Coinbase can set you up a wallet for all the money you'll be making!

Cloudflare.com
They will also help protect you, or you could set the whole thing up there probably.

x402 documentation
Coinbase’s implementation documentation and quick-start material for payment-gated HTTP resources.

x402 Foundation repository
The open-source reference implementation, SDKs, examples, and specification materials.

HTTP 402 Payment Required
The web status code x402 builds on. It has existed for decades; the useful part is finally giving software a standard payment response to act on.

OWASP API Security Top 10
Read this before exposing any API that touches valuable data, money, or customer information.

OpenAPI Specification
A clear machine-readable contract is part of the product when your buyer is another piece of software.

The internet trained us to think that valuable information must either be free, ad-supported, hidden behind a giant subscription, or sold through a sales call.

That model made sense when the buyer was a person with a credit card and a browser tab.

Agents are different. An agent may only need one answer. It may need it at 3:14 a.m. It may be perfectly happy to pay a few cents, provided the endpoint is reliable and the rules are clear.

That's a worthwhile thing to examine building and defending.

Thanks for reading this newsletter! Feel free to respond any time.

Thomas

Was this forwarded to you? Subscribe at builddefend.fyi.

Had enough? [Unsubscribe] - no hard feelings.*

* Well, a little bit.