Skip to content
APIs.Dev
Get started

The Verifier

View as Markdown
Open in

The Verifier checks a seller from outside against the open contract, and signs what it finds. No seller and no platform grades itself.

An attestation, from request to replaced

Filled: a state someone outside the run sees. Hollow: a private state, a step inside the run.

What keeps it honest

RuleWhat it means
Paid per check, whatever the resultA seller cannot buy a pass; a failed check costs what a passed one costs
Methods in the openThe suite, the sampling and the windows are published, so anyone runs the same checks
ReproducibleA check names its calls, and anyone who replays them against the pinned Version gets the same result
Its own keysAn attestation verifies against the Verifier's key list, with no call to the seller or to APIs.Dev
Nothing to sellA Verifier never lists, ranks or sells products, and never takes a share of a sale
ContestableA seller names the calls it disputes; the Verifier reruns them and signs again, or keeps its result with a reason

Who runs it

A Verifier is run by a party apart from APIs.Dev and from every seller, under its own name, its own Host and its own keys.

Any party may run one, provided it runs the open conformance suite and publishes its methods. A buyer's selection policy names the Verifiers it trusts, by Host, and ignores the rest.

APIs.Dev runs none. It pays for the checks its plans include, at the Verifier's posted price, and copies each attestation into the offer card unchanged.

When an attestation lapses

An attestation goes stale when its window ends without a new one, and a buyer's policy treats a stale seller as unproven.

A revoked attestation leaves every offer card within the hour. The Verifier lists it with its reason, for any agent that saw it earlier.

A buyer that trusts one Verifier

A buyer trusts one Verifier and buys only from sellers it attests at paid or above, on APIs.Dev or not.

buyer.ts
14 lines
import { define, mandate } from 'apis.dev'

/** Acme's research agents, buying from any seller a trusted Verifier attests. */
export default define({
  name: 'acme-research', domain: 'acme.com',
  buy: {
    budget: { month: 200 },
    choose: { verified: true, success: 0.99, unproven: 'refuse',
              verifiers: ['verifier.example.org'],   // the one it trusts
              level: 'paid' },                       // pays per call, no account
    approve: { above: 2, by: 'finance' },
    researcher: mandate({ month: 150, task: 20, for: '90d' }),
  },
})

The attestation it reads sits in each seller's offer card, signed by the Verifier.

Attestation
14 lines
{
  "contract": "1",
  "by": "verifier.example.org",
  "host": "facts.example.com",
  "level": "paid",
  "window": "90d",
  "calls": 4200,
  "verbs": [
    { "name": "Company.get", "success": 0.997, "median": "180ms",
      "conforms": true }
  ],
  "signed": "2026-10-28T06:00:00Z",
  "signature": "ed25519:Rk7tB2vQ9xLm4Zc1Hf8Wn3Jp6Ya0Ds5u"
}

On APIs.Dev, and off it

A product on APIs.Dev is checked on every publish, and hourly on Scale.

A seller elsewhere asks a Verifier for checks, and pays its posted price.

Either way the attestation reads the same. An agent ranks two sellers by the same fields, whichever platform each runs on.

A private deploy

The site, the portal and the docs behind an enterprise sign-in, an IP allowlist or both, with the API on its Keys and the prices public while the product sells.

Data governance

How a product treats the data it holds: classes on fields, controller and processor, a generated DPA, people's requests, customer-held keys and the data chain.