Skip to main content

​
Verification

Arclasp exposes two current verification surfaces:
  1. Authenticated v2 verification for authorized organization users.
  2. Tokenized public verification for sharing a bounded verification result outside the account.
Legacy compatibility routes may remain operational, but new integrations should use the v2 surfaces.

​
Authenticated verification

Authenticated v2 endpoints include:
Authenticated responses can expose richer verification context than the public surface because the caller is authorized inside the organization. Depending on the artifact, verification can report layers such as:
  • integrity;
  • signature status;
  • signing-key trust;
  • timestamp-anchor status;
  • receipt-chain continuity;
  • current evidence/governance status;
  • overall verification status.
Not every historical artifact is guaranteed to have every modern layer. A layer may legitimately be absent or reported as not_applicable, unsupported, or indeterminate.

​
Public verification

Admins can issue an opaque token for eligible evidence. The public verification route uses that token:
Treat the token as a bearer secret for the bounded verification result it unlocks. The public response is intentionally minimized. It should not expose private reviewer notes, raw credentials, raw signatures, signing keys, token hashes, or full internal evidence payloads.

​
One-time token disclosure

When a public verification token is created, the plaintext token is returned once. Arclasp stores a hash rather than a recoverable plaintext copy. If the link is lost, revoke the old token and issue a new one rather than expecting the plaintext token to be retrievable later.

​
Admin token management

Current authenticated management routes include:
Do not put real API keys, public verification tokens, signing keys, raw signatures, or proof secrets in documentation, logs, screenshots, or support messages. Artifact IDs may still be needed for ordinary troubleshooting; they are not interchangeable with bearer tokens or cryptographic secrets.

​
SDK helpers

The supported top-level SDK exposes:
The exact response model depends on the verification surface and caller role.

​
What verification proves

Verification is about the integrity and status of Arclasp evidence. It does not automatically prove:
  • the outside world changed exactly as described;
  • the customer instrumented every relevant tool action;
  • legal admissibility;
  • legal non-repudiation;
  • regulatory compliance.
Do not construct new public links from raw approval or receipt UUIDs. Use the opaque public token flow for new externally shared verification links.