APIs.io rates a catalog it is listed in

This page exists so the conflict is stated rather than discovered. It is written to be quotable against us; anything softer would read as legal cover, and the only value a document like this has is that a hostile reader finds nothing in it they could not have found themselves.

The two roles

As a Provider, APIs.io publishes APIs, holds a profile in its own catalog, and carries a Kin Score computed by the same rubric applied to everyone else.

As the Directory, APIs.io holds the register of participants, issues the attestations consumers present to providers, and decides who is enrolled and who is removed.

UK Open Banking held these apart deliberately — OBIE is not a bank. We have chosen differently. The conflict is real, and it is accepted rather than resolved. Those are different words and only the second one would be a claim we could not support.

What the conflict is, specifically

Three places the roles pull against each other, named plainly, because a conflict nobody has enumerated cannot be checked.

1. Rating a competitor. The Kin Score ranks providers and APIs.io is ranked among them. A scoring decision that advantaged our own record would be invisible to anyone who could not reproduce the score.
2. Gating enrolment. The Directory decides who is enrolled and who is revoked. Those decisions could be used commercially — to exclude, to pressure, or to advantage a partner.
3. Attestation as leverage. A consumer’s ability to reach providers depends on facts we publish about it. Withholding or delaying one is a commercial instrument if nobody is watching.

What actually constrains it

Four things, and they are narrower than the four this page used to list. In August 2026 we decided this framework is a product, not a standard — and that decision removed constraints as well as obligations. Listing constraints we no longer have would be worse than having fewer.

• The rubric is public and the score is reproducible. Every check, weight and band cut is published on the rating page. A provider who disputes a score can compute the result themselves before appealing, and can publish an artifact and be rescored. This is the load-bearing one: it is what makes a disputed rating answerable without trusting us.
• Correction is free, and always will be. Any participant can tell us our data about them is wrong, at no cost, through the same door as anyone else. A rating product that charged to fix its own error is the one thing that would be genuinely indefensible.
• Removals carry a stated basis. Nobody is removed without a recorded reason, on the same discipline the delisting registry already runs: an entry removed without a basis is not a decision, it is a rumour with our name on it.
• Our own record is scored by the same rubric, published on the same pages, and we write up where we fall short of it — see the gaps on the blueprint, which are ours.

What we do not claim

• No regulatory standing. There is no supervisor here. Nobody has authority over the Directory and there is no appeal beyond us. That slot is named and left empty on purpose rather than filled with an implication.
• Not neutral. We are not neutral by nature; we are constrained in the four specific ways above, and observable. Only the second is a claim we can support.
• No separated key material. An earlier draft of this page promised that Directory attestations would be signed by a key distinct from the one APIs.io uses as a Provider, at a different issuer, under a different rotation policy. That was traded away with the product decision and this page says so rather than quietly keeping the sentence. It existed so a provider could verify an attestation without trusting the operator; a product’s customers trust the operator by definition. Reversing it later means retrofitting key separation onto attestations already in circulation, which is the expensive direction — worth knowing, not worth pre-building.
• No scheme rules document. The governance artifacts a framework would need — scheme rules, a register interface specified for third parties, a published rotation policy — became ordinary product documentation. There is no rules document binding the Directory that a third party could hold us to.
• The register is not the market. Enrolment is an act. A provider profiled in the catalog is not enrolled, and the register says so. A large share of catalog records are stubs nobody has participated in — measured at roughly 40% on 2026-08-26, and that number should improve, so quote it with its date or not at all.

What would resolve it

Nothing that is currently scheduled, and that is the honest answer.

The earlier answer was a second directory: the specification would live in API Commons, this instance would be one implementation, and once providers verified against both the conflict would stop being structural and become a choice participants make. The product decision dropped the requirement that anyone else could implement the Directory, so that route is not being built toward.

What replaces it is weaker as governance and more useful day to day: the rubric is public, every score is recomputable, and correcting an error we made is free. A provider who disagrees can recompute rather than appeal.

If that is not enough for your purposes, it should not be — and the right response is to weight our numbers accordingly rather than to take this page’s word for anything.

Part of the trust layer. The vocabulary behind it is on the seven roles.