AERDocumentation

Guide

Operating AER

The controls a platform team runs day to day: webhooks and digests for findings, retention and visibility for records, share links for auditors and the export surface for everything else.

Findings, pushed to you

Register a webhook and AER delivers findings and session completions as signed HTTP posts: each delivery carries an HMAC signature header (x-aer-signature-v2) computed under a per-webhook secret you can rotate at any time, plus a delivery history endpoint for audit and replay. For a daily summary instead of a push per event, set a digest address in Settings: at most one email per 24-hour window listing the new findings, cleared by removing the address.

POST /v1/webhooks                       {url, event_types?}
POST /v1/webhooks/:id/test              fire a test delivery
POST /v1/webhooks/:id/rotate-secret     rotate the HMAC secret
GET  /v1/webhooks/:id/deliveries        delivery history

Retention and visibility

Records are retained indefinitely by default. Setting bundle_retention_days (1 to 3650) auto-expires the bundle bytes after the window while keeping the searchable metadata; the transparency-log entry is permanent by design. Setting bundle_visibility to private gates every bundle-content endpoint behind tenant auth, and per-record share links re-open exactly one record to whoever holds the link: scoped, expiring (24 hours by default, 30 days at most), revocable and audited.

PATCH /v1/tenant/settings               {bundle_visibility?, bundle_retention_days?, anchoring_enabled?, notification_email?}
POST  /v1/aers/:id/share-links          {expires_in_seconds?} → single-record URL
GET   /v1/aers/:id/share-links          list, with active flags
DELETE /v1/aers/:id/share-links/:sid    revoke

Exports

Every record exports as canonical JSON (what is signed), W3C PROV-JSON for provenance tooling, a self-contained evidence pack ZIP (canonical bundle, provenance, verification script, public key, anchor evidence and a manifest with the SHA-256 of every file) and OTLP logs and traces for your observability stack. OTLP is interop, not the analysis path: the console's search and feeds work on the records first-hand.

GET /v1/aers/:id/bundle           canonical JSON (the signed artifact)
GET /v1/aers/:id/prov.json        W3C PROV-JSON
GET /v1/aers/:id/evidence.zip     self-contained offline audit pack
GET /v1/aers/:id/otlp-logs.json   OTLP logs (tenant auth)
GET /v1/aers/:id/otlp-traces.json OTLP traces (tenant auth)

The audit chain

Every privileged action on your tenant lands in a tamper-evident hash chain you can verify yourself: GET /v1/audit lists it and GET /v1/audit/verify recomputes the chain and cross-checks its anchor. A broken link is loud, not silent.

Keys and roles

API keys carry a role: read, write or admin. Reads need read (every key passes), session and agent writes need write, and anything that mints credentials or is destructive needs admin. Keys can be pinned to one agent and principal at mint, and a pinned key can never mint a wider one. Mint scoped keys from your root admin credential for agents and teammates; revoke any key except the one you are using.