> ## Documentation Index
> Fetch the complete documentation index at: https://docs.go.aiinsurance.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Close and re-open events through dedicated lifecycle endpoints

An event (a claim or an incident) closes and re-opens through **two dedicated
action endpoints**, not through the generic entity update:

| Method | Path                                                    |
| ------ | ------------------------------------------------------- |
| `POST` | `/api/v1/companies/{companyId}/events/{eventId}/close`  |
| `POST` | `/api/v1/companies/{companyId}/events/{eventId}/reopen` |

Each moves `eventStatus`, stamps or clears the event's **Close Date**, and
appends an entry to the event's open/close-history log — **in one transaction**.
Both require `company.claim:create`.

## Why the status has its own endpoints

The status does not travel alone. The lifecycle dates a claim reports — opened
on, previously closed on, re-opened on — are derived from the open/close-history
log, so a status change that skipped the log would silently misreport them. A
`PATCH` to `/entities/event/{entityId}` that changes `eventStatus` is therefore
rejected with `409` (`GuardedStatusFieldWrite`), and the message names the
endpoint to use instead — see [Flow-written status
fields](/api-reference/entities/overview#flow-written-status-fields) for how
this interacts with the generic entity surface.

Two things are deliberately unaffected:

* **Creating** an event with an explicit `eventStatus` still works, which is how
  a historical import loads claims that were already closed.
* A `PATCH` that sends `eventStatus` with the value it already holds is always
  accepted, so an update that merely echoes the status is unaffected.

## The effective date

Both endpoints take one required input, `effectiveOnDate` — the date the action
**takes effect**, which may be earlier than today (typically the day the
adjuster closed or re-opened the file). 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, or re-opened before the
close it reverses.

## Endpoints

* [Close Event](/api-reference/event-lifecycle/close-event) — status becomes
  `closed`, **Close Date** is stamped with the date you send, and a `close`
  entry is appended to the log.
* [Re-open Event](/api-reference/event-lifecycle/re-open-event) — status returns
  to `open`, **Close Date** is cleared, and a `reopen` entry is appended. The
  log entry is what preserves the previous close date: it is what a claim's
  "previously closed on" is read from.