Skip to main content

History Recording

Procivis One maintains a single, centralized log of events across the entire deployment. This page explains how that log works: where events come from, what triggers an entry, and how write access is controlled. To search, filter, and export recorded events, see Searching and Reading History.

A single, centralized log​

Core is the sole system of record for history. Other services in a Procivis One deployment (the Enterprise Backend, OpenID Bridge, Wallet-Relying Party Registry) do not keep their own separate audit logs. Instead, each forwards its events to Core's history API, which records them in one central store.

This means that regardless of which service in your deployment performed an action, the resulting entry lands in the same log, searchable and exportable through a single interface. Each entry's source field identifies which service reported the event, so you can always trace an entry back to its origin even though everything is stored centrally.

What creates a history entry​

History entries represent state-changing events on the entities the platform manages, not every operation the system performs. Broadly, entries fall into a few categories:

  • Creation and deletion of entities such as credentials, keys, certificates, and wallet units
  • Lifecycle and status transitions, such as a credential being suspended or a wallet unit being revoked
  • Completion of interactions, such as a credential being offered, shared, or accepted
  • Domain-specific events particular to a given component, such as trust resolution or receipt of a Wallet-Relying Party Access or Registration Certificate

CHECK THESE

Example entityExample actions
CredentialCreated, Offered, Issued, Pending, Accepted, Shared, Revoked
Wallet unitCreated, Activated, Issued, Pending, Revoked, Updated
Trust list subscriptionCreated, Updated, Deleted

The table above is illustrative, not exhaustive. For the full set of entity and action types, see the entityTypes[] and actions[] enums of GET /api/history/v1.

How entries reach the log​

Non-Core services never write to Core's database directly. Instead, they call Core's history API to submit events as they occur:

  • POST /api/history/v1 — used by other services to forward an event to be recorded

See History in the Core API reference for full endpoint details.

Write access and permissions​

Creating a history entry requires the HISTORY_CREATE permission, assigned to the technical users representing the non-Core services that report events to Core. This permission should never be assigned to a real user; see Configuring Service History for setup and why this matters.

Reading history is governed separately, through HISTORY_LIST / HISTORY_DETAIL (scoped to your organization) or SYSTEM_HISTORY_LIST / SYSTEM_HISTORY_DETAIL (cross-organization). See Across organizations for how query scope works.

No modification after creation​

The history API provides no way to edit or delete an existing entry, only to create new ones. Correcting or reversing a state is recorded as a new entry (for example, a Revoked entry following an Issued one), never by altering a previous entry. This makes the log append-only through the API; direct access to the underlying database is outside the scope of this guarantee.