API keys

The primary endpoint needs no credential at all. POST /v1/verifications answers anonymously.

A key buys three things, and none of them is a different verdict:

• a higher rate limit,
• a durable verification log you can reconcile against,
• your own reference echoed back on every verification.

You need one to list or read verifications back — those operations are credentialed.

Getting a key

Settings → Organisation → API credentials, in the portal. An admin or a signatory can issue one, once they have completed their own identity verification.

The secret is shown once, at creation, and is never retrievable afterwards. Store it where you store other production credentials; if you lose it, revoke it and issue another rather than hunting for it.

Keys are minted in the portal only, by a signed-in person. An API key cannot mint another API key — a credential that can create credentials is an escalation surface.

Scopes

Every key carries exactly one scope: verifications:read. It is what this API requires.

Scopes only ever subtract. Your organisation's API access is checked first, and a scope can never grant beyond it — so widening a scope on a key cannot widen what the organisation is entitled to.

Rotation

Several keys can be active at once. Rotation is therefore three steps:

1. Issue the replacement.
2. Deploy it.
3. Revoke the old one once traffic has moved.

There is no cutover window and no coordinated switch.

A key expires 365 days after it is issued, and then returns 401. The lifetime is fixed and there is no expiry picker, so keys minted at different times expire at different times. Record the issue date of every key you deploy and rotate before it lapses.

Revocation

Revocation takes effect immediately. There is no propagation delay to wait out, and no cache that keeps a revoked key working.

Revoking a key does not affect verifications already performed with it — your reconciliation log survives the credential that produced it.

live and test

A key's prefix selects its environment. There is no separate hostname and no separate account.

The two are isolated, not ranked. Neither is a permission level, and choosing one does not change what you are entitled to. The prefix partitions your credentials and your reconciliation log, and that partition is enforced on every read.

Validation status affects your disclosure tier — how much detail a response carries — never whether a key works.

If a key leaks

Revoke it yourself, immediately, from Settings → Organisation → API credentials. Then issue a replacement — because several keys can be active at once, you can roll the new one out before retiring the old.

A leaked key exposes your verification log — the SHA-256 of every document your organisation has verified, and every reference you attached, which is why matter numbers and case ids do not belong in that field. It also lets the holder write to that log and spend your rate limit.

It does not expose your documents. Audrie holds hashes, never content, so a key cannot read a document from your account — but a hash identifies a file to anyone who already holds it.