Skip to main content
DEVELOPERS · EVENTS · PREVIEW

External systems
via Events.

The Events interface is the intended design for state-change-driven notification to external systems. External systems are designed to register a destination and receive platform events when relevant state changes occur.

EVENT MODEL

State change. Event. External system.

The intended Veritan event model is designed around state-change notification. When a platform state change occurs, the intended design emits an event directed toward registered external systems. External systems are designed to receive structured, verifiable notification without polling the platform.

STATE CHANGE NOTIFICATION

The Events interface is designed for state-change-driven notification — when a record, credential, or authority state changes, the intended model emits an event rather than requiring external polling.

SUBSCRIPTION MODEL

External systems are intended to register for the event categories relevant to their integration. The subscription defines what events are directed to which destination endpoint.

DELIVERY MODEL

The intended delivery model directs events to a registered endpoint. The design intent is for the receiving system to acknowledge delivery. Delivery implementation details are preview-stage architecture.

DELIVERY ARCHITECTURE

From Veritan to your endpoint.

The intended model: external systems register a destination endpoint and subscribe to event categories. The platform is designed to emit an event to the registered endpoint when a matching state change occurs. The receiving system is designed to acknowledge the delivery. The illustrative format below shows the intended event structure — not a production delivery contract.

EVENT DELIVERY — ILLUSTRATIVEHTTP
POST https://your-endpoint.example.com/veritan/events
Content-Type: application/json
Veritan-Signature: sha256=<hmac-signature>
Veritan-Event-Id: evt_••••••••••••
Veritan-Timestamp: 2026-08-18T00:00:00Z

{
  "event": {
    "id": "evt_••••••••••••",
    "type": "veritan.<domain>.<event-name>",
    "record_id": "<record-id>",
    "state": "active",
    "evidence": { "provenance": {...}, "authority": {...} },
    "occurred_at": "2026-08-18T00:00:00Z"
  }
}

→ 200 OK  (your system acknowledges delivery)

Event types follow the format veritan.<domain>.<event-name>. Actual event names are confirmed at integration time against the canonical event registry.

SUBSCRIPTION MODEL

Subscribe to the events your system needs.

The intended model configures event subscriptions per project with an explicit event category list. External systems are designed to receive only the events they registered for. Subscriptions are intended to be created, updated, and revoked from the Console or via the API.

ENDPOINT REGISTRATION
The intended model: register a destination URL per project. Endpoints are designed to be verified before the first delivery.
EVENT CATEGORIES
Subscribe to specific event categories: record lifecycle, evidence updates, authority changes, provenance events.
DELIVERY INTEGRITY (PREVIEW)
The intended design includes a verification layer so external systems can confirm event origin and integrity. Specific implementation details are preview-stage architecture.
DELIVERY RELIABILITY (PREVIEW)
The intended delivery design accounts for endpoint unavailability. The specific reliability model is preview-stage architecture.
VERSIONING
Event schemas are intended to be versioned. Schema changes are designed to be announced with migration guidance before deployment.
NEXT

Access the Console.