Re-open Event
Re-opens a closed event (a claim or an incident) as of a date you choose, in
one atomic call: the event’s status returns to open, its Close Date is
cleared, and a reopen entry is appended to the event’s open/close-history
log.
Use this instead of setting eventStatus. As with
Close Event, a PATCH to
/entities/event/{entityId} that changes eventStatus is rejected with a
409 (GuardedStatusFieldWrite) — the status and the log move together.
effectiveOnDate is required. It is the date the claim reports as
re-opened on, and the platform has no way to infer it. It is also what
preserves the previous close date: clearing Close Date would otherwise
lose it, and the log entry is what a claim’s “previously closed on” is read
from.
The log cannot run backwards. effectiveOnDate must be on or after the
last entry already in the event’s log — in practice, on or after the close it
reverses. An earlier date returns 409
(EventLifecycleDateOutOfOrder) naming the date it has to clear; the same
day as the close is allowed.
Required permission: company.claim:create
Authorizations
API key authentication. Send your raw API key as the Authorization header value with NO scheme prefix — Authorization: YOUR-API-KEY. Do NOT prefix it with Bearer or ApiKey, and do not use an X-API-Key header; those are not accepted.
Path Parameters
Company identifier
Event (claim or incident) identifier
Body
The calendar day a lifecycle action takes effect.
Deliberately narrower than Fmv1Date:
a lifecycle action records a wall-clock DAY, so there is no timezone and no
ISO { date: "YYYY-MM-DD" } alternative — send year, month and day.
Any other key is ignored.
The date must be a real calendar day (2026-02-31 is rejected) and fall
between the years 1900 and 2200.
