Event catalogue
Published verbatim from Gungner’s Brayns partner interface pack, version 1.6.0 (
events.md). This page is not edited here.
The event log is cursor-based, ordered per tenant, at-least-once — see semantics.md §6 for cursor semantics (including the invalid-cursor 400). Every event carries schema_version.
| Type | Payload | schema_version |
|---|---|---|
company.changed |
pinned | 1 |
company.status.changed |
pinned | 1 |
person.changed |
pinned | 1 |
refresh.completed |
pinned | 1 |
refresh.deferred |
pinned | 1 |
screening.cleared |
pinned | 1 |
screening.hit |
pinned | 1 |
signatory.changed |
pinned | 1 |
subject.merged |
pinned | 1 |
subscription.created |
pinned | 1 |
subscription.ended |
pinned | 1 |
subscription.expiring |
pinned | 1 |
subscription.resumed |
pinned | 1 |
subscription.suspended |
pinned | 1 |
ubo.changed |
pinned | 1 |
The five change types, the two refresh types and the subscription.* lifecycle types are emitted by monitoring (SPEC-005 / ADR-011): a subject produces events only while an active subscription carries its legal basis, and every payload carries that subscription id, the canonical subject id with aliases, and trigger (on_demand | scheduled). screening.hit/screening.cleared are emitted by SPEC-004b, one per completed check, carrying the check id, the band and the policy, override, source and matcher versions it was produced under — never a name or a birth date. person.changed is declared but not yet emitted: SPEC-003b ships the person read path, and a scheduled person source — what a periodic person check reads, and how often — is not built yet, so a person subscription monitors a permit rather than a person for now (see semantics.md §7). GET /v1/events?types= filters this same stream; see semantics.md §6–7.