API

Public API

Der Production API Origin für SDKs und öffentliche Verification ist https://verify.attesto.eu. Tenant Browser Workflows laufen auf https://dashboard.attesto.eu.

Die richtige API Family wählen

Attesto hat mehrere öffentliche Surfaces, weil Evidence Work an verschiedenen Stellen passiert. Verwenden Sie SDK/API von Ihrem Server, um Evidence zu erstellen, Webhooks für Lifecycle Notifications, Connectors für Source-system Observations und Verifier Endpoints, wenn ein anderes System Evidence prüfen muss, bevor es ihr vertraut.

Origins

Authentication

Server-side Event Ingest verwendet einen Tenant System Key im Authorization: Bearer Header. Public Verification Routes validieren gelieferte Proof Objects und benötigen keine Tenant Cookies. Tenant Dashboard Routes verwenden die bestehende sichere Browser Session plus CSRF recovery für mutating requests. Legen Sie keine system keys oder SSO client secrets in frontend bundles.

curl -X POST https://verify.attesto.eu/v1/sdk/events \
  -H "Authorization: Bearer $ATTESTO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $ATTESTO_IDEMPOTENCY_KEY" \
  --data-binary @event.json

Email-first authentication routes

Main tenant users melden sich über Email Discovery auf dashboard.attesto.eu an. Attesto gibt genau einen empfohlenen next step zurück, statt alle Provider gleichzeitig zu zeigen. Marketplace developer accounts, admin staff auth und auditor auth bleiben getrennte Surfaces.

Siehe Tenant SSO für den Entra ID, generic OIDC und SAML setup guide.

Source time und timezone policy

Attesto speichert, wann das Source System ein Event als passiert meldet, und wann Attesto es empfangen hat. Event APIs verlangen timezone-aware timestamps wie 2026-06-07T12:00:00+02:00 oder 2026-06-07T10:00:00Z. Tenant timezone ist konfigurierbar; Systems erben standardmäßig die Tenant Timezone und können eine eigene source_timezone setzen, wenn die verbundene Quelle in einer anderen Jurisdiktion läuft.

Idempotency und Replay Behavior

Write Routes akzeptieren Idempotency-Key. Wiederholung desselben Keys mit demselben canonical Request gibt das Original Result zurück. Wiederholung desselben Keys mit einem anderen Request schlägt als Conflict fehl. Das schützt Connector Retries und server-side Job Retries vor doppelter Evidence.

v1 Event Ingest

Verwenden Sie v1, wenn Sie den stable Event Audit Trail und Anchoring Path benötigen. SDKs setzen Defaults für Event Type, Status, Retries und Idempotency.

• POST /v1/sdk/events loggt ein Event.
• POST /v1/sdk/events/batch loggt bis zu 1000 Events.
• GET /v1/events/{eventId}/proof gibt anchored proof material für ein Event zurück.
• POST /v1/public/verify verifiziert ein v1 Proof Object.
• POST /v1/exports/{exportId}/truth-package/verify zeichnet ein backend-validated truth_package.verified Event auf, nachdem ein Verifier Report beweist, dass das exportierte Package kryptografisch geprüft wurde.

Tenant dashboard v1 APIs

Diese browser APIs betreiben dashboard.attesto.eu. Mutating calls nutzen Tenant Session Cookies und CSRF recovery. Verwende System Keys und SDK routes für server-side ingest; verwende diese Routes für Tenant Operators, die ihre Workspace verwalten.

Minimaler Event Body:

{
  "type": "ai.decision",
  "status": "verified",
  "occurred_at": "2026-06-07T12:00:00Z",
  "source_ref": "case-2026-0001",
  "payload": {
    "model": "risk-classifier-v4",
    "decision": "manual_review",
    "policy_id": "policy-2026-01"
  }
}

v2 Proofstream

Proofstream fügt append-only Streams, signed Receipts, Windows, Checkpoints, Witness Evidence, Anchors, Bundles und Offline Verification hinzu.

• POST /v2/streams erstellt einen Stream.
• POST /v2/streams/{streamId}/events hängt ein Event an und gibt ein signed Receipt zurück.
• POST /v2/streams/{streamId}/events/batch hängt mehrere Events mit Receipt Results an.
• GET /v2/streams/{streamId}/head gibt den aktuellen append-only Stream Head zurück.
• GET /v2/receipts/{eventId} gibt das gespeicherte Receipt zurück.
• POST /v2/verify/receipt verifiziert ein Receipt Object direkt.
• GET /v2/windows/{windowId} gibt Window Evidence und Inclusion Material zurück.
• GET /v2/checkpoints/{checkpointId} gibt Checkpoint Evidence zurück.
• GET /v2/checkpoints/{checkpointId}/consistency?from=... gibt Consistency Evidence zurück.
• GET /v2/witness/policies/{policyId} gibt die Witness Policy für Quorum Checks zurück.
• GET /v2/anchors/{anchorEpochId} gibt Anchor Epoch Evidence zurück.
• GET /v2/ivc/epochs/{ivcEpochId} gibt Proof of Evolution Epoch Evidence zurück.
• POST /v2/audit/packs erstellt ein Offline Verifier Bundle, wenn die Range die erforderliche Witness und Anchor Evidence hat.
• POST /v2/verify verifiziert Receipt, Stream, Checkpoint, Consistency, Anchor, IVC oder Bundle Objects.

Einen Stream erstellen:

curl -X POST https://verify.attesto.eu/v2/streams \
  -H "Authorization: Bearer $ATTESTO_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<JSON
{
  "system_id": "sys_...",
  "use_case": "ai-decision-history",
  "policy_id": "policy-2026-01",
  "metadata": {
    "owner": "risk-platform",
    "environment": "production"
  }
}
JSON

Ein Event anhängen:

curl -X POST https://verify.attesto.eu/v2/streams/$STREAM_ID/events \
  -H "Authorization: Bearer $ATTESTO_API_KEY" \
  -H "Idempotency-Key: $ATTESTO_IDEMPOTENCY_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<JSON
{
  "source_ref": "case-2026-0001:decision-1",
  "event_type": "ai.decision",
  "occurred_at": "2026-06-07T12:00:00+02:00",
  "payload": {
    "decision": "manual_review",
    "score": 91,
    "policy_id": "policy-2026-01"
  }
}
JSON

Receipt Response Shape:

{
  "stream_event_id": "sev_...",
  "stream_id": "str_...",
  "seq_no": 1,
  "event_hash": "sha256-hex",
  "stream_head_hash": "sha256-hex",
  "receipt": {
    "protocol": "ATTESTO-PROOFSTREAM-001",
    "alg": "Ed25519",
    "kid": "proofstream-receipt-key",
    "signature": "hex-encoded-signature"
  }
}

Tenant Proofstream und dashboard APIs

Tenant browser APIs zeigen dasselbe Evidence Model im Dashboard, ohne Frontend-Zugriff auf server-side system keys. Mutating dashboard calls verwenden browser cookies und CSRF recovery.

Tenant settings und SSO APIs

Tenant settings sind nur für authenticated tenant users mit der nötigen Rolle verfügbar. Provider secrets werden server-side verschlüsselt und nach dem Speichern nie an den Browser zurückgegeben.

Connector und Local Vault APIs

Connectors sind production evidence sources. Tenant users konfigurieren connector records im Dashboard, während source systems Events über provider-specific signed envelopes oder Local Vault relay posten. Jedes connector event muss source system, source object, source event type, source timestamp mit timezone, idempotency reference und ein normalized payload commitment enthalten.

Marketplace APIs

Marketplace APIs betreiben marketplace.attesto.eu. Der public catalog ist read-only. Tenant acquisition, installation, artifact download und revocation benötigen eine authenticated tenant session plus CSRF. Publisher signup, profile management, developer checkout, payout onboarding und asset submission verwenden ein separates marketplace-only developer account. Öffentliche Docs lassen private Attesto review- und publication-endpoints bewusst aus.

Public status API

status.attesto.eu exponiert customer-safe health für öffentliche Services. Enthalten sind component status, latency, uptime bars, incident summaries, generated time und timezone metadata. Nicht exponiert werden private admin status, tenant identifiers, logs, secrets, provider payloads oder raw database details.

• GET https://status.attesto.eu/health gibt status-service health zurück.
• GET https://status.attesto.eu/api/status gibt den public status payload der Seite zurück.
• GET https://status.attesto.eu/v1/status ist der versioned status payload alias.

Siehe Public status page für das public visibility model und die component list.

Verification Behavior

Verification schlägt fail-closed fehl bei malformed objects, changed payloads, changed sequence numbers, removed oder inserted events, stale checkpoints, wrong witness signatures, wrong anchors und ambiguous fork evidence.

Truth Package Downloads und Verification sind getrennte Lifecycle Events. Ein Download zeichnet truth_package.accessed auf und beweist, dass das Package ausgeliefert wurde. Ein erfolgreicher Verifier Report an /v1/exports/{exportId}/truth-package/verify zeichnet truth_package.verified auf und beweist, dass ein Verifier Package Hash, Manifest Hash und enthaltene Artifacts geprüft hat. Der finale ZIP Hash wird nach Finalisierung der ZIP Bytes aufgezeichnet und nicht wieder in dieselbe ZIP eingebettet; das vermeidet Circular Self-reference und hält die herunterladbaren Bytes unabhängig hashbar.

curl -X POST https://dashboard.attesto.eu/v1/exports/$EXPORT_ID/truth-package/verify \
  -H "Authorization: Bearer $ATTESTO_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @truth-package-verification-report.json

curl -X POST https://verify.attesto.eu/v2/verify \
  -H "Content-Type: application/json" \
  --data-binary @attesto-bundle.json

Error Semantics