Read one verification back

Stable id for this verdict — use it to read the verdict back and to reconcile. A UUID. organisation tier only.

An anonymous verification is attributable to no one and is not retained, so it has none. A credentialed request from an organisation being validated is served at the public tier and so carries none either — but it is attributed to your organisation and retained, and appears in your log once validation completes.

Audrie's answer about the submitted document. It fails closed: anything we cannot fully substantiate is never verified. Treat any value you do not recognise as not verified.

A document authenticated moments ago answers no_record for the short window before its record is submitted to Hedera, then pending_anchor until finality. If you verify immediately after authenticating, retry rather than concluding the record was lost.

Where several records match one hash, the verdict is a single reduction across all of them. This is the precedence, and the first value any match produces is the answer:

signature_invalid → verified → verified_org → revoked → pending_anchor

So one tampered record is enough to answer signature_invalid, and one healthy anchored authentication is enough to answer verified or verified_org. Between those two, a match signed by a person outranks one signed by an organisation's system key: a hash carrying both answers verified, and verified_org means every healthy match was signed by an organisation.

The scalar therefore asserts only that SOME match produced the winning value. A verified or verified_org answer does not mean every match is healthy — a revoked record for the same hash is invisible in it — and it attributes the document to nobody. Read each match's own status and signerType rather than inferring either from the scalar.

sandbox sits outside that reduction, because a live record for a hash always answers first. An anonymous caller or a live credential sees sandbox only when Audrie's check for a live record finds none already accepted for anchoring against this hash. A record you have just authenticated — before Hedera accepts it — or one whose submission failed, is not visible to that check, so a sandbox record for the same hash can answer sandbox in that window. In full mode, this check is keyed by the recordId you send, not by the hash. The answer carries matches: [] and matchesTruncated: false — no anchor, signer or revocation detail, whatever state the sandbox record is actually in. A test credential sees only sandbox records: reading its OWN organisation's sandbox record for a hash, it gets sandbox in place of what would otherwise be verified or verified_org, in full match detail, with revoked, signature_invalid and pending_anchor reported as themselves so it can exercise every branch. Another organisation's sandbox record reads to a test credential exactly as it reads to an anonymous caller — collapsed to sandbox, with no detail.

A sandbox record does not last: we delete our sandbox record of it after 30 days; its hash remains on the Hedera test network, which we do not control.

How much this response was permitted to disclose. Read it rather than inferring it from whether you sent a key. Treat any value you do not recognise as public.

Disclosure tiers has the full comparison.

How strong this verdict is. Always present.

audrie.registry.v1 means the verdict was recomputed server-side from the anchored registry, with no certificate artifact issued. Read the field explicitly rather than hardcoding the value, and never treat its absence as a default.

What the verdict was computed over — see mode on the request.

GET /v1/verifications/{verificationId} and the list operation return the mode recorded for that verification, not just POST /v1/verifications's immediate response.

The environment of the key that produced this verdict, taken from its prefix. organisation tier only.

The two are isolated, not ranked: a test key never sees live verifications and neither is a permission level. A verification recorded under test is checked only against sandbox records: your own organisation's in full detail, and another organisation's collapsed to the sandbox verdict (see Verdict).

A SHA-256 digest — sha256: followed by 64 lowercase hex characters. Uppercase hex and a bare digest with no prefix are both refused.

When Audrie computed this verdict. RFC 3339 timestamp, UTC.

Echoed verbatim from the request. organisation tier only.

Anchored records matching the hash, ordered by anchor time, earliest first. Empty for no_record and pending_anchor, and also for revoked when the revocation lies beyond the 25-record window described below.

mode: partial returns at most 25 records, and verdict is computed over the records returned, plus — for revoked only — a check that also covers records beyond these 25. A hash reaches 25 only when many parties independently authenticate identical bytes; if that is your use case, contact us.

verdict can be revoked even when no revoked record appears here: Audrie checks for a revocation on this hash beyond the 25 records returned. That beyond-window revocation reaches verdict only when none of the returned matches already yields verified, verified_org or signature_invalid — those outrank it. When one does, the revocation surfaces nowhere in the response; matchesTruncated: true is the only signal that the list may be hiding one. Read matchesTruncated to see whether this list itself may be incomplete.

mode: full returns at most one record — the one named by recordId in the request. no_record here means the id, kind and hashes were not all confirmed together; see full mode in the operation's description for why those causes are not distinguished.

Whether the underlying match lookup reached the 25-record limit and may hold more records than matches shows. false means the lookup is complete. It does not say how many further records exist, only that there may be more — and it can be true while matches is empty: a revocation beyond the 25-record window can turn verdict revoked without any of the returned records being the revoked one. Always false on mode: full, which resolves exactly one record and has no 25-record window to reach.

Present only on POST /v1/verifications, which recomputes matches and can answer definitively. Reading a recorded verdict back — GET /v1/verifications/{verificationId} and the list operation — never recomputes matches, so both omit this field rather than assert a stale answer.

Seconds to wait before retrying. Present on a pending_anchor verdict from POST /v1/verifications, and on no other verdict. Reading a recorded pending_anchor verdict back does not carry it.