Skip to main content
DEVELOPERS · API · PREVIEW

REST API.
Evidence-bearing response model.

The preview API model is designed around versioned contracts for application integration. Intended responses carry machine-readable evidence, provenance, authority scope, and record state.

← DevelopersMCP Surface
AUTHENTICATION

Bearer token. Project scoped. Environment isolated.

Every Veritan API request is designed to authenticate with a project credential. Development and production environments are designed to be strictly isolated. Credentials are designed to be scoped to explicit capability sets and designed to be rotatable and revocable from the Console.

EXAMPLE — NOT A PRODUCTION ENDPOINTHTTP
# Production-scope credential (illustrative — not a live credential):
Authorization: Bearer vrtn_example_••••••••••••

# Development-scope credential (illustrative — not a live credential):
Authorization: Bearer vrtn_example_••••••••••••
REQUEST MODEL

Structured request. Evidence-bearing response.

The intended request model specifies the record, the capability scope, and the evidence fields required. The designed response model includes the structured result plus machine-readable evidence so downstream systems can verify, not just consume.

EXAMPLE — NOT A PRODUCTION ENDPOINTHTTP
POST /v1/records/verify
Authorization: Bearer vrtn_example_••••••••••••
Content-Type: application/json

{
  "record_id": "<record-id>",
  "evidence_scope": ["provenance", "authority", "state"]
}

→ 200 OK
{
  "record": {
    "id": "<record-id>",
    "state": "active",
    "version": 3
  },
  "evidence": {
    "provenance": {
      "origin": "...",
      "chain": [...],
      "verified": true
    },
    "authority": {
      "issuer": "...",
      "scope": ["verify", "read"],
      "valid_until": "..."
    },
    "state": "active"
  },
  "verified_at": "2026-08-18T00:00:00Z",
  "request_id": "<request-id>"
}
API SURFACE

Capabilities available via the API.

The intended Veritan API surface exposes core platform capabilities through a consistent versioned contract. Endpoint paths, request schemas, and response fields will be documented in the developer reference once available.

RECORDS
The intended interface for creating, reading, updating, and verifying records. Responses are designed to include current state and the evidence chain.
EVIDENCE
The intended interface for requesting evidence for a record: provenance chain, authority scope, state transitions, and verification timestamps.
PROVENANCE
The intended interface for inspecting the complete provenance chain for any record, traceable to origin.
AUTHORITY
The intended interface for verifying the authority scope of a given credential or operator action against a record.
CREDENTIALS
The intended interface for managing project credentials: list, create, scope, rotate, and revoke. Credential values are not returned in responses.
USAGE
The intended interface for per-project request counts, evidence lookups, and audit log entries for billing and compliance review.
ENVIRONMENTS

Development and production are designed to be strictly separated.

The intended model uses clearly prefixed development credentials that are never valid against production data. Production credentials are designed to be scoped explicitly and rotatable through the Console. Environment mixing is intended to be prevented at the platform layer.

DEVELOPMENT · EXAMPLE

vrtn_example_••••••••••••

Illustrative development-scope credential. Shown to explain environment separation. Not a live credential or available production service.

PRODUCTION MODEL · EXAMPLE

vrtn_example_••••••••••••

Illustrative production-scope model. Shown to explain environment separation only. Not a live credential or generally available production service.

AUDIT MODEL · EXAMPLE

vrtn_example_••••••••••••

Illustrative read-only audit-scope model. Shown to explain scope separation. Not a live credential.

ERROR MODEL

Structured errors. Machine-readable codes.

Veritan API errors return structured JSON with machine-readable codes, the affected scope, and resolution guidance. Error categories are stable across API versions.

EXAMPLE ERROR RESPONSEJSON
→ 403 Forbidden
{
  "error": {
    "code": "authority.insufficient_scope",
    "message": "Credential scope does not permit this operation.",
    "scope_required": "verify",
    "scope_held": ["read"],
    "request_id": "<request-id>"
  }
}
NEXT

Explore the MCP surface.

MCP ↗EventsConsole