Close Event
Closes an event (a claim or an incident) as of a date you choose, in one
atomic call: the event’s status becomes closed, its Close Date is
stamped with the date you send, and a close entry is appended to the
event’s open/close-history log.
Use this instead of setting eventStatus. A PATCH to
/entities/event/{entityId} that changes eventStatus is rejected with a
409 (GuardedStatusFieldWrite). The status and the log have to move
together — the lifecycle dates a claim reports (opened on, previously closed
on, re-opened on) are derived from that log, so a status change that skipped
it would silently misreport them. Creating an event with an explicit
eventStatus is unaffected: a historical import still loads closed claims
directly.
effectiveOnDate is the date the closure TAKES EFFECT — typically the
day the adjuster closed the file, which may be earlier than today. The date
you acted is recorded separately by the platform and is not settable.
The log cannot run backwards. effectiveOnDate must be on or after the
last entry already in the event’s log; an earlier date returns 409
(EventLifecycleDateOutOfOrder), and the message names the date it has to
clear. The same day as the previous entry is allowed. In practice this means
an event cannot be closed before the day it was opened.
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.
