Every API's documentation tells you what it does. Almost none tell you what they built and decided not to ship, which is a shame, because that list says more about how the thing is run than the feature list does.
Mine has four entries. All four are written. None of them serve a request.
The monitoring product
Two of the four are a pair, and together they were a product: you create a monitor on something you care about, and it wakes up on a cadence and checks.
monitor/create costs 0 credits, deliberately. A monitor sitting there doing nothing is worth nothing — what costs money is the round, so the round is what should be billed. Charging for creating one would have been charging for intent.
monitor/check costs 1 credit, and it charges whether or not it finds anything. That's the opposite of my usual rule, and on purpose: the work of waking up, resolving the cadence and running the check happened regardless of the result. The endpoint it checks then bills its own part separately, by its own rule — so archive/movers, which costs nothing when nothing moved, still costs nothing inside a monitor round.
I like that design. It is also switched off.
The honest reason is that a monitoring product is a promise about the future — you are telling someone their thing will be watched, on a schedule, indefinitely. I could not, at the time I built it, promise the uptime that promise requires. Shipping it anyway would have meant quietly not-watching things people believed were being watched, which is worse than not offering it.
That is the whole story. Not a technical blocker. A promise I wasn't ready to make.
The history endpoint
archive/history costs 5 credits and returns the trajectory of one item through the archive: where it ranked, and its points, over time.
Five credits is a lot to charge for what the archive can currently return, and that is why it's off. The endpoint works. But the archive's depth is uneven across niches — some have months of hourly windows, some have days — and a history call that costs five credits and returns three points because that niche is thin is a bad trade for the person paying.
The endpoint that tells you how deep the archive goes per niche is archive/coverage, and it costs 0 credits, because it is discovery and not product. That one is live. It is the one you would need in order to know whether archive/history is worth five credits for your niche.
So the sequence is inverted: I shipped the free tool that measures whether the paid tool is worth it, and held the paid tool until more niches are worth it. When the depth is there, it turns on.
YouTube
youtube/channel reads the official Data API v3, and it has never been active. Two reasons, and the second is duller but more decisive.
The subscriber count is not a number the platform publishes precisely. Google rounds subscriberCount to three significant figures above a thousand subscribers, and has since 2019. There is no exact value on any public surface — unlike TikTok, where an exact counter sits next to the rounded one. Returning the rounded figure is defensible; I just want the catalogue to say clearly which platforms give a precise count and which don't, and that distinction has to be written down before the endpoint ships, not after.
There's a neighbour field I explicitly rejected: hiddenSubscriberCount. When a channel hides its count, the API returns subscriberCount: 0. Publishing that zero would state that a channel has no subscribers. It has a count; you're just not allowed to see it. Those are different facts and a null is the only honest way to say the second one.
The data path was never proven. The API key lives as a secret, and the local tooling masks it, so the endpoint has never completed a real call in an environment I could inspect. An endpoint that has not been observed working is not an endpoint, whatever the code says.
And a third thing, which is operational rather than principled: the key shares a daily quota with the archiver, which already spends roughly 7,272 of its 10,000 daily units. Switching YouTube on without sorting that out would mean the archiver starts failing at some hour of the day, for reasons nobody would connect to a new endpoint.
Why publish this at all
Because "what it doesn't do" is the question every integration has to answer eventually, and the usual way to find out is to build against an API for two weeks and discover the gap yourself.
There's a second reason, less generous: a catalogue that only shows the working parts is a catalogue you can't check. If I publish nineteen live endpoints and say nothing else, you have no way to tell whether I have four disabled ones with reasons, or forty abandoned ones with none. Publishing the disabled list with a reason attached to each is the only version of the claim that can be falsified.
Every one of these is in the same table that serves the requests, with an ativo flag. The OpenAPI spec is generated from that table with ativo = true, which is why these four don't appear in it — the spec cannot promise something the router won't serve, because both read the same row.
What is actually live
Nineteen endpoints. Profile data for ten platforms — Instagram, TikTok, Threads, Bluesky, Pinterest, SoundCloud, Mastodon, GitHub, Linktree and Medium. Recent posts for Threads, Bluesky and Mastodon. Repository data for GitHub. The archive's niche rankings, movers and coverage, and the hour-by-hour history of any profile someone has already looked up. And account, which reports your own balance and costs nothing, because reading a number should not change it.
Prices are here, generated from the same table. Every key gets 1,000 credits a month free, no card.
If one of the four above is the thing you need, tell me — a real use case is a better argument for switching something on than my own roadmap is.
Endpoint states and credit costs read from the live catalogue on 25 September 2026. YouTube Data API v3 behaviour as documented by Google; the rounding of subscriberCount above 1,000 subscribers has been in place since 2019.