Event

Don’t put your own claim numbers in the Event ID. The platform generates the Event ID (eventReferenceId) for every new event, whether it’s created in the app or through the API. The API still accepts a value for it, but we strongly recommend that you never send one.If your claims already have a number from another system, such as a carrier, TPA or legacy claim number, add a field for it to your configuration, for example a Text field claimNumber labelled Claim Number, and load the number into that field. A field of your own can be placed on the event page, shown as a list column, filtered, exported, and edited like any other field. The Event ID stays the platform’s own identifier for the event.

Connects to	How
Policy	Each event is reported against one policy. A policy can have many events.
Exposures	An event references the exposures it touches (many-to-many) — a single incident can involve several.

API. Managed through the unified entity CRUD surface as event. See the Entities API overview.Framework-required fields.

Field	Notes
`eventName`	Read-only. Recomputed by the platform on every save: `userSetEventName` when that is set, otherwise derived from the exposures and claimant (`DERIVE_EVENT_NAME(referencingExposures, claimant)`).
`userSetEventName`	Text. The name a user gave the event through Rename Claim / Rename Incident; empty while the event carries its derived name. Setting it re-titles the event and pins the title; clearing it hands the title back to the derivation.
`eventType`	Option Set (e.g. Claim / Incident).
`eventStatus`	`open` or `closed`, set by the platform from the last entry of `eventOpenCloseHistory`; every write keeps the two in agreement (an event written before this rule can still disagree until its `closedDate` or log is next written). A value sent on create or update is ignored; close and re-open the event through the Event Lifecycle actions, which move the status and append to the log together.
`eventReferenceId`	The Event ID. Generated by the platform when the event is first saved. A value sent on create or update is accepted, but strongly discouraged: store an existing claim number in a field of your own instead (see the warning above).
`eventCoverageType`	Option Set.
`eventDate`, `reportDate`	Dates.
`closedDate`	Date — the effective date of the log’s last entry when that entry is a `close`; empty while the event is open. Sent on create, it closes the event: the platform adds a `close` entry after the `open` one, and refuses a date before the open date (`400`); sent with a history, it must match the history’s last entry, a `close`. On a closed event an update moves the log’s last `close` with it, never earlier than the latest open or re-open by exact time (`409 EventLifecycleDateOutOfOrder`); the update may add `effectiveAt` inside it, the exact time of that close (see Editing the Closed Date). Clearing it on a closed event, or setting it on an open one, is refused (`400`): re-open or close the event instead. The date it already holds, in the same timezone and with no time or the close’s own time, is not an edit.
`eventOpenCloseHistory`	List of Objects — the event’s open / close / re-open log. Each entry carries `actionTakenDate`, `effectiveOnDate`, `action` (`open`, `close` or `reopen`) and `effectiveAt`, the exact moment the action takes effect (a UTC timestamp on the day of `effectiveOnDate`), with `effectiveTimeKnown` false when the platform chose that time because none was given, as it did for every entry written before November 2026 (see The exact time). The platform appends an entry when an event is created, closed or re-opened, and on create builds it from `openedOn` / `closedDate`. It stays writable: sent on create (a historical import) or on update, it must be a complete, well-formed log (`400`). Either way the status and `closedDate` follow its last entry. A Closed Date edit moves its last `close` (or adds one).
`openedOn`	Date, read-only except on create — the effective date of the `open` entry with the earliest `effectiveAt` in the log. On create it dates the `open` entry the platform builds (default: the day of creation in `America/New_York`); sent with a history, it must match the history’s `open` (`400`). Recalculated from the log after that, so an update’s value is ignored.
`reopenedOn`	Date, read-only — the effective date of the `reopen` entry with the latest `effectiveAt`, the one listed last on a tie; empty when the event has never been re-opened. A re-open at 10 PM in Los Angeles that came after one at 12:30 AM the next day in New York is the most recent, although its date is earlier.
`previousClosedOn`	Date, read-only — the effective date of the `close` the log lists just before that re-open; empty when the event has never been re-opened, or when no `close` is listed before it. The log’s order decides, so a claim re-opened and closed again on the same day reports the close before the re-open.
`isReopened`	Boolean, read-only — whether the event has ever been re-opened. Empty (rather than `false`) on an event that has not been written since these fields were added.
`referencingPolicy`	The policy this event is reported against (singular; reverse-read).
`referencingExposures`	Exposures this event touches (tenant-defined expression).
`contacts`	People linked as contacts (join to Person).

Additional fields are configured per company; discover them via the /entities/event/configuration endpoint.

Overview

Insurance entities

Directory entities

How its data works

What it connects to

Files, Notes & Contacts