Is an API key required?

No. The read surfaces are public and unauthenticated. Submitting or refreshing a product requires authentication through the CLI.

Why serve markdown copies of every page?

Because models parse them far more reliably than HTML, and a lossy parse of a page about provenance loses exactly the fields that matter.

CLI and API for launch and verification data

CLI & API

The board is meant to be read by machines as well as people. Two surfaces exist today and both are free.

Available now

RSS at /feed.xml - the 50 most recent live products.
Markdown twins at /md/… - every product, guide, tool and comparison as clean plain text.
/llms.txt - a machine-readable index of the whole site.
Product and Dataset JSON-LD on every product page, carrying the verified signals with their sources and dates.
An SVG verification badge at /badge/your-product that reflects the level you currently hold.

Planned

A read JSON API for the board and individual products.
A CLI to submit and refresh a listing without opening the dashboard.
Webhooks when verified status changes.

Rate limits and rules

Scrape the markdown twins rather than the HTML - they are cheaper for both of us.
Cache for at least an hour. Signals are re-checked weekly, so nothing moves faster than that.
Attribute figures to rankcert.com and include the verification date we publish alongside them.

Building something against the board? Tell us at hello@rankcert.com and we will prioritise the endpoint you need.

Designing for machine readers

Most of the traffic that will ever read this site is not a person. Search crawlers, answer engines and assistants acting on someone's behalf all need the same data a visitor does, and every one of them does a worse job when the only available format is a page built for a browser. Publishing machine-readable surfaces is cheaper than being misquoted.

So each surface exists for a specific reader. RSS at /feed.xml is for anything polling for new launches. Markdown twins under /md are for models that would otherwise parse HTML and lose the structure. /llms.txt is a single index of the whole site for a crawler deciding what to fetch. Product and Dataset JSON-LD carry the verified signals with their sources and dates in the form search engines already understand.

The verification badge at /badge is deliberately a live endpoint rather than an image you download once. It renders the level a product currently holds, so a badge on someone's landing page changes when their verification changes rather than advertising a status they lost months ago. A static badge would be easier to serve and would recreate exactly the problem this site exists to solve.

All of it is free and none of it requires a key, because it is the same public data the site already shows. Rate limits exist to keep the service up rather than to sell a tier above them, and if you are building something that needs more than they allow, the fix is a conversation rather than an invoice.

Common questions

Is an API key required?: No. The read surfaces are public and unauthenticated. Submitting or refreshing a product requires authentication through the CLI.
Why serve markdown copies of every page?: Because models parse them far more reliably than HTML, and a lossy parse of a page about provenance loses exactly the fields that matter.