Skip to main content
Anyone can resolve a DID and verify it without logging in. The verification endpoints are public and read-only, so a third party — a reviewer, a funder, a downstream researcher — can confirm a record is authentic for themselves. Replace $DATAERAI_SERVER with your Dataerai host in the examples below.

Resolve a DID

Resolving returns the DID’s current state — its kind, status, visibility, and a verification result. A resolved record reports verified: true only when both checks below pass. The status field describes the record’s lifecycle: The response also reports visibility (public or private) and gated (whether reading the DID requires access). A public DID resolves for anyone; a private/gated DID has no anonymous surface (see below).

What “verified” means

When both hold, the record is provably authentic and provably logged — it cannot have been forged or quietly inserted after the fact.

Public endpoints

Verify content integrity

A DID commits to the record’s content, not just its metadata. The verify-content endpoint confirms the file content has not changed since it was signed — so you can prove a dataset is byte-for-byte what it was when you cited it.

Verification keys

GET /api/identity/keys/ returns the public keys anyone uses to verify. Keys can rotate over time; records signed under an earlier key keep verifying, because each record records which key signed it.
Verification is fail-closed: an unknown or misconfigured key never silently downgrades the result to “verified.” If a record cannot be proven authentic, it is reported as unverified.

The audit log

GET /api/identity/{did}/log/ returns the record’s full history — its creation and every edit since — as a signed, append-only chain. Each entry is part of the same tamper-evident log, so the history itself is verifiable, not just the current state.

Gated DIDs and access

A private (gated) DID has no anonymous public surface. An anonymous caller — or anyone without access — who resolves a gated DID gets a 404, the same response as an unknown DID, so the endpoints never leak whether a private record exists. People who can already read the record (the owner and anyone it’s shared with) resolve and verify it normally.

Share a gated DID

To let an external reviewer verify a gated DID without publishing it, the record’s creator or an admin can mint a time-boxed read capability for that one DID:
ttl is the lifetime in seconds (capped by the server). The response returns a capability token. The reviewer passes it on any resolve or verify request — either as a header or a cap query parameter — to unlock just that one DID:
The token grants read and verify access to that single DID only, and it expires. Replace $DATAERAI_SERVER with your host and $DATAERAI_TOKEN with an OAuth2 access token — see Authentication.

Next steps

Publish & cite

Make a DID public and get its did:web document for citation.

Provenance tokens

The other signed artifact on every asset — who created it.