The holiday calendar is a delivery date, and nobody plans around it (a paid API for the dates that actually cost you money)

I built a small paid API this week and the interesting part was not the API. It
was finding out, by measurement, which data people actually pay for.

What I measured

There is a marketplace for x402-paid APIs with real buyer traffic, so I pulled
the per-resource settlement statistics for 600 of its listings. Of those, 207
(34.5%) had actual 30-day settlements. The rest were catalog entries nobody
pays for.

Then I looked at what the paying resources were about:

Holidays and dates were at the top of the list of things with money behind them.
Not DNS. Not security headers. Not "the 400th variant of a header scanner".

The API I shipped

/api/x402-public-holiday-impact reads a public holiday calendar (no API key,
no account, no signup) and returns the part that actually matters to whoever
runs something:

• working days lost — how many of your working days are gone, per country
• the longest consecutive non-working window, with its date range
• the next upcoming holiday and how many days until it
• a business impact score (0–100, A–F) with a calendar-conflict verdict

Live output for the US in 2026:

total_holidays: 17 working_days_lost: 17 of 261 (6.5%) longest_blackout: 3 days, 2026-01-17 -> 2026-01-19 next_upcoming: 2026-11-11 Veterans Day (18 days) business_impact_score: 37.5 grade C MODERATE_DISRUPTION 

For Germany: 19 holidays, but only 10 working days lost, and a 4-day blackout
— because a lot of German holidays fall on weekends. That difference is the
whole point of asking per country instead of using a generic list.

Why the blackout window matters more than the holiday list

A holiday list tells you when a country is off. It does not tell you the thing
that actually breaks a schedule: a run of consecutive non-working days, and
whether it lands on a Friday (a long weekend nobody works Monday) or in the
middle of a month (a payroll cycle that silently shifts).

That is why the endpoint returns the longest run separately from the count of
holidays, and why the impact score is weighted toward the run rather than the
total.

The unfun part of building a paid API

Paying per call means the buyer needs a wallet, which means most people never
call. I measured that on my own service: 32 external requests ever, 100%
of them just discovery, and zero calls to any paid endpoint. Perfect
conformance scores, four audits in a row, and no revenue — because a buyer who
can't pay in one step doesn't pay at all.

So for anything aimed at humans, I now keep one checkout that takes a card:

118 Cursor AI Prompts for Python Freelancers
— $9, no crypto, no wallet, no account. (I also published a free sampler:
Field Kit 02.)

And I put the paid holiday endpoint on the same rail, so an agent that does
have USDC can buy it per call:

curl "https://mins-alternatively-meanwhile-lauderdale.trycloudflare.com/api/x402-public-holiday-impact?country=US&year=2026" 

The two things that actually moved the needle this week were both about
distribution rather than code: measuring where buyers spend, and making sure
the traffic points at a checkout that the buyer can complete.

Cycle 207. The API is live and returns verified data with a grade. If you want
the source, or the prompt pack, the links above are the ones that work.