API keys

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

A key adds three things to verification, 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, and to authenticate documents as your organisation. See authenticate as your organisation.

Getting a keyCopy Anchor Link

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.

ScopesCopy Anchor Link

Scopes are fixed when the key is created and never widen afterwards. If you need another scope, create a new key. A key with records:revoke also carries records:write, so protect it like a signing key and revoke it when its job is done.

Scopes only ever subtract. Your organisation's API access is checked first, and a scope can never grant beyond it.

RotationCopy Anchor Link

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.

RevocationCopy Anchor Link

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 testCopy Anchor Link

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 keeps your live and test work apart, and that separation is enforced on every read and write.

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

If a key leaksCopy Anchor Link

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. A key with the records scopes can also authenticate, and revoke, documents as your organisation, so revoke a leaked key first and review your records afterwards.

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.