API
The same record this site publishes, read-only, as JSON: an HTTP API at /v1 and an MCP server exposing the same reads as tools for an assistant. Both are free, versioned, and rate limited, and neither can write to the ledger. Nothing on either is for sale. About says why.
Getting a free key
POST /v1/keys with a JSON body holding one field, email, the address the key is issued to. That address is the only thing stored about the caller; a body carrying anything else is refused rather than silently kept. The key comes back in the response and is then sent as the X-API-Key header on every other route. No route ever asks for a card, an account, or anything beyond that one address.
Issuing a key needs no key of its own, which means it cannot be rate limited per caller the way every other route is: there is no identity to limit it by, because none is collected. It is instead capped as a whole: 200 new keys a day, across every caller, as a backstop rather than a per-caller allowance.
The daily allowance
One tier, free, with these limits. They are published here and nowhere stricter: the same numbers are what api.metering enforces and what GET /v1 states back to a caller in its own response, so the allowance shown here cannot drift from the one applied.
If this table is wider than the space it has here, scroll it sideways to see every column.
| Limit | Free tier |
|---|---|
| Requests per day | 1000 |
| Requests per second | 5 |
| Evidence extracts per day | 10 |
Every answered request carries its standing in RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset headers, so a caller never has to be refused once to find out where they stand.
Routes with an allowance of their own
One route carries a second, smaller allowance on top of the shared daily requests above, because an evidence extract is a document built from every published file behind an answer, not a row of one:
If this table is wider than the space it has here, scroll it sideways to see every column.
| Route | Daily allowance | Response headers |
|---|---|---|
/v1/extracts | 10 | RateLimit-Extracts-Limit, RateLimit-Extracts-Remaining |
What going over any of these costs: none. The request is refused, not charged for.
What is counted, and what is not
Every admitted call is recorded as one row: usage(day, key_id, route, count). A calendar day, the key that called, the name of the route (the pattern it matches, such as /v1/entities/{id}, never the value it was called with), and a count. That is the whole record.
What is not recorded is as deliberate as what is, because it is the opposite of what a metered API usually keeps:
- No IP address.
- No user agent.
- No query text or parameters. A search, a country filter or a date is never written to the usage record, only the route name it was sent to.
- No provider or company name. The evidence-extract route is the clearest case: asking whether a named company was on a list is recorded as one call to
/v1/extracts, exactly like every other call to it, never as a record of which company was asked about.
A usage table that named who was asked about would be a second, quieter register of the same companies this record tracks. It is not kept.
The MCP server
The MCP server speaks JSON-RPC 2.0 over stdio, as provider-ledger, protocol revision 2025-06-18. It has no network address to visit: it is run alongside the assistant that uses it, as python -m mcp.server, and configured with the same key issued above through the LEDGER_API_KEY environment variable. Run with no key, it still serves reads, unmetered, over whatever export directory LEDGER_EXPORTS names.
Every tool it exposes reads exactly the same record as the HTTP route named beside it, through the same query layer, and is counted under that route’s name and allowance when a key is configured. One key’s usage reads the same whichever door it came through.
If this table is wider than the space it has here, scroll it sideways to see every column.
| Tool | Route | Answers |
|---|---|---|
find_providers | /v1/entities | Companies on an official list, by country, status or a name search. |
get_provider | /v1/entities/{id} | One company, every official list record it holds, and any withdrawal recorded against it. |
list_official_records | /v1/providers | Raw official records, one per listing per source, not deduplicated into companies. |
list_countries | /v1/countries | Every jurisdiction tracked, with its official sources and their reuse terms. |
get_country | /v1/countries/{code} | One jurisdiction in full: its sources, mandate detail and current counts. |
list_withdrawals | /v1/withdrawals | Providers removed from an official list, each with the snapshot pair that proves it. |
list_changes | /v1/changes | The hash-chained event feed: what changed on an official list, and when. |
official_records_on_date | /v1/as-at | Who was on an official list in one country on one past date. Whether a listing is an approval is stated by the basis the record returns, and on both of this register’s active lists that word is ‘recognised’ rather than an approval. Called accredited_on_date until 12 October 2026; that name still answers and is no longer listed. |
get_evidence_extract | /v1/extracts | A dated, checkable extract for an audit file: was this company on this list on this date. |
Every tool that can return a list record returns basis and the authority’s own quoted statement alongside it. Read what basis means before reporting one as an approval.
This page is information taken from official published lists. It is not tax, legal or professional advice, and it does not replace checking the official source.