I Put a Tollbooth on an API Just to See If AI Agents Would Pay

AI has made side projects super simple to create - and I had an itch I needed to scratch. As with all projects like this, what started as a simple idea, “when is the next bank holiday?”, turned into an experiment to see whether LLMs would pay for simple data, rather than making it up or spending GPU power to figure it out.

Working out bank holidays is hard - if you live the UK you know the pain. There’s different bank holidays for England and Wales, Scotland, Northern Ireland - and sometimes these dates do not land on the same day each year. That being said, when I delved into other countries bank holidays - I found that the UK system of bank holidays appears to be simple, especially when compared against regional holidays in Spain! Are LLMs smart enough to understand these nuances between regions?

The TL;DR is that I ended up building https://nextbank.holiday

It covers 41 regions across the UK, Ireland, France, Germany, and Spain in four languages. If a human lands on the site, it geolocates your region, displays the exact date with zero clicks, and costs nothing.

That took less than a day. But once the baseline was working, I decided to test something that had been nagging at me for months: what happens if you ask an AI agent to pay for data?

The Plumbing: Spec-Driven and Single-Worker

I didn’t want a complicated stack for this. All of my projects now run on Cloudflare - and Cloudflare make deploying static websites super simple.

Following strict spec-driven development, the entire service was built over three days. It runs entirely on a single Cloudflare Worker.

Alongside the browser frontend, I built*:

1. Deterministic JSON endpoints for automated consumers.
2. iCal subscription feeds by region.

3. A remote Model Context Protocol (MCP) server, allowing LLMs to natively query next bank holiday dates directly through tool-calling.

4. There is a workflow which runs once a week, which commits back into itself with the range of bank holiday days. No manual updates, no guessing floating Easter dates.

Once the machine-readable interfaces were live, the real question surfaced: how should the service handle automated consumers?

*“I” is doing some heavy lifting here. It was pair-programming with a model against a strict specification, naturally.

Reviving HTTP 402

HTTP 402 has been getting a bit of attention recently - at least from the posts and ideas I’ve personally seen floated around. From what I know, HTTP 402 has been around for a long time - but not used until now. It was built for a future cash system that never happened - leaving the modern web reliant on subscriptions, API keys and advertising.

Now, we have autonomous agents making tool calls. We also have high-speed, low-fee layer-2 networks.

Instead of slapping a CAPTCHA or similar across the site to block automated traffic, I implemented the x402 protocol:

• For humans: Free forever. Zero ads, zero friction.
• For ordinary scripts and curl: Free, with a rate limit.
• For identified AI agents (GPTBot, ClaudeBot and friends): The first 100 requests per day are entirely free. The allowance is shared per user-agent family, not per client, and resets at 00:00 UTC.
• Beyond 100 requests: The API returns 402 Payment Required and requests $0.001 in USDC on Base.

1
2
3
4
5
6
7

HTTP/1.1 402 Payment Required
content-type: application/json; charset=utf-8
cache-control: no-store
payment-required: <base64 JSON>
x-free-quota-limit: 100
x-free-quota-remaining: 0
x-free-quota-reset: 2026-10-12T00:00:00Z

I didn’t build this to make money. The financial expectation is zero. The goal is observation - how do automated clients behave when an endpoint asks for a micro-fraction of a cent?

Do they drop the connection? Do they retry until rate-limited? Do they alter user-agents to masquerade as desktop browsers? Or will an autonomous framework actually pay the invoice and keep going?

I wired up a Slack webhook so I get alerted when the site or the payment path breaks, plus a daily digest of what the agents did. Every request is also recorded - client group, outcome, user-agent family, no IP addresses - and shown live on the site’s /about page. It’s an interactive honeypot for agent behaviour.

The Plumbing Still Bites

Reading about micropayments is easy; actually wiring up a live mainnet settlement pipeline over a weekend is a different story.

I originally wanted to use Cloudflare’s native payment architecture, but that remains in closed preview. That meant rolling up my sleeves and dealing with real crypto pain:

1. Discovering that Binance is effectively sidelined for UK retail trading meant rethinking my setup.
2. Dusting off and recovering an old Coinbase account just to fund an operational wallet.
3. On the plus side, developer tooling has matured significantly. Setting up Rabby wallet was a breath of fresh air compared to how clunky getting a decent wallet was years ago.

The Facilitator Wild West

Knowing you want to support HTTP 402 is one thing - actually picking the rails to settle it is where the headache begins.

The x402 specification relies on a “facilitator” - a middleman that verifies the cryptographic payment signature and handles the on-chain settlement so your Cloudflare Worker doesn’t have to run a full blockchain node just to check if an agent sent you a tenth of a cent.

My first stop was OpenX402. On paper, the documentation was actually fine - the technical mechanics were laid out well enough. The problem was credibility.

Outside of X (Twitter), the project had virtually zero footprint. No established presence, no recognisable production implementations, and no real engineering discussion beyond social media cheerleading. And the kicker? The docs said no sign-up, but you couldn’t set anything up until you paid a 5 USDC registration fee - a fee that isn’t mentioned in the documentation. You had to pay before you could even evaluate the service.

When something like this exists mostly in social media threads and asks for money upfront before you can test a single request, it is hard not to be cautious. It could be entirely genuine, but without an established track record, paying blind felt like an unnecessary gamble.

Therefore, I looked at alternatives and found PayAI.

PayAI was the complete opposite: some credibility, clear implementation, and - no registration, no key, and a free tier of 1,000 settlements a month.

So What?

If you want to understand how autonomous systems will alter the web, go and start building endpoints that interact with them!

We are moving away from an internet built purely for human eyes looking at banners, toward an internet where software consumes software on behalf of users.

Blocking agents entirely is born of fear and letting them drain your compute for free is poor engineering. Setting a clear, machine-readable boundary - a generous free tier followed by a micro-fee via HTTP 402 - is the pragmatic middle ground.

The result so far? Every payment has been me testing with my own wallet. No real agent has paid.

What it appears real agents do instead is hit the 402 and leave - they read the toll sign and turn around. Fair enough.

The tollbooth works - but no agent has driven through it yet.

If you just want to know when your next long weekend is, head to nextbank.holiday. It’s free.

If you are building an autonomous agent with a wallet, the API is waiting. Bring your $0.001.