curl --request POST \
--url https://go.aiinsurance.io/api/v1/companies/{companyId}/events/{eventId}/close \
--header 'Authorization: <api-key>' \
--header 'Content-Type: application/json' \
--data '
{
"effectiveOnDate": {
"date": "2026-08-05",
"timezone": "America/New_York"
}
}
'{
"eventId": "550e8400-e29b-41d4-a716-446655440020",
"eventStatus": "closed"
}Close Event
Closes a claim or incident (event) as of the date you choose. Use it,
not Update Entity (updateEntity), to close a claim. Re-open Event
(reopenEvent) reverses it, and Replace Event Open/Close History
(replaceEventOpenCloseHistory) loads or corrects past closes.
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 Closed 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. The field is system-managed:
a value sent for it — on create or on a PATCH to
/entities/event/{entityId} — is silently ignored, and the status follows
the event’s open/close-history log instead. 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. To load a claim that is already closed, create it with its
openedOn and closedDate, and the platform builds the log open then
close; or supply its full eventOpenCloseHistory (on create, or via
PUT /events/{eventId}/open-close-history). Either way the platform derives
the status from the log’s last entry. To correct the date an event already
closed on, edit its closedDate with a generic PATCH (see
Editing the Closed Date)
rather than re-opening and closing again, which would record a re-open that
never happened.
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.
effectiveAt is the exact moment, optional. Send a timestamp with an
offset or Z (2026-08-05T14:30:00-05:00) on the day of
effectiveOnDate, read in that date’s timezone; it is stored in UTC, to the
second, on the log entry. Without it, the entry takes the current time when
effectiveOnDate is today in its timezone, and otherwise the start of that
day, marked effectiveTimeKnown: false. Closed Date stays a date.
The log cannot run backwards. The close may not be earlier than the last
entry already in the event’s log, compared by exact time; an earlier one
returns 409 (EventLifecycleDateOutOfOrder), and the message names both
moments. A tie is allowed, and an entry whose time nobody gave
(effectiveTimeKnown: false) counts as the start of its day. A date sent
without effectiveAt is fine unless the last entry has a real time later
that same day: then the 409 asks for effectiveAt and gives the earliest
time allowed. In practice this means an event cannot be
closed before it was opened.
Required permission: event.close
curl --request POST \
--url https://go.aiinsurance.io/api/v1/companies/{companyId}/events/{eventId}/close \
--header 'Authorization: <api-key>' \
--header 'Content-Type: application/json' \
--data '
{
"effectiveOnDate": {
"date": "2026-08-05",
"timezone": "America/New_York"
}
}
'{
"eventId": "550e8400-e29b-41d4-a716-446655440020",
"eventStatus": "closed"
}Authorizations
Path Parameters
Body
Field Model V1 Date value: a calendar day pinned to an IANA time zone —
the day a person wrote on the policy, not an instant.
date is the day as YYYY-MM-DD and must name a real calendar day
(2026-02-30 is rejected with 400). timezone is an IANA tz database
identifier (e.g. America/New_York, UTC); an unknown zone is rejected
with 400. On a write timezone may be omitted, in which case it defaults
to America/New_York. Every value the API returns carries both members.
importedAsUnknownTimezone is optional boolean provenance. When true, the
import did not know the source timezone and used a fallback. It does not
change date interpretation. CALENDAR_DATE sets it when no timezone is
supplied. Omission does not prove the source timezone was known: older
imports did not record this information. Selecting a timezone explicitly
in the date picker clears the marker.
This is the one Date shape the API accepts, stores and returns, for every
field typed Date — entity fields, policy term dates, custom-object
sub-fields, embedded exposure items and the event lifecycle dates alike.
Event lifecycle dates are narrower: Close and Re-open's effectiveOnDate,
the dates in an open/close history sent to Replace Event Open/Close History,
on a create or on an update, and an event's openedOn and closedDate when sent on
create or changed on update must fall in the years 1900–2200, in a supported
timezone. The retired { day, month, year, timezone } spelling is refused
with 400
(see the API changelog, 2026-09-08). The policy endorsement deltas channel
additionally requires both members stated, because it stores each value
exactly as sent (2026-09-04).
Show child attributes
Show child attributes