Skip to main content
An event (a claim or an incident) closes and re-opens through two dedicated action endpoints: Each moves eventStatus, stamps or clears the event’s Closed Date, and appends an entry to the event’s open/close-history log — in one transaction. Close requires event.close; re-open requires event.reopen. A generic PATCH, which needs event.edit, moves the status only by sending the whole log (see Editing the Closed Date), as PUT /events/{eventId}/open-close-history does.

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. eventStatus is therefore a system managed field: a value you send for it on a generic create or PATCH to /entities/event/{entityId} is silently ignored — the status follows the log’s last entry instead — see Flow-written status fields for how this interacts with the generic entity surface. To load a claim with its real dates, send them when you create it: openedOn, the day the claim opened, and for a closed claim closedDate, the day it closed, in the Create Entity body’s entityData. The platform builds the log from them — open on openedOn, then close on closedDate — and the claim is created closed. Both take the same dates as Close Event’s effectiveOnDate (a real day in the years 1900–2200, in a supported timezone). Without openedOn the claim opens on the day it is created (in America/New_York), so a past closedDate needs openedOn too: a close before the open returns 400. The app sends openedOn as today in the creator’s timezone, so a claim created in the app opens on their calendar. Building the log is a write of eventOpenCloseHistory: if your configuration gives that field a field write group, the create needs that group, or returns 403 field-write-permission-required. An openedOn sent alone and dated today in its own timezone needs no group: it is the open the platform adds anyway. A historical import with a fuller log, re-opens included, supplies the event’s eventOpenCloseHistory instead: on create (an openedOn or closedDate sent with it must agree with it), or through PUT /events/{eventId}/open-close-history or a generic PATCH. All three require a well-formed log: an open entry, then alternating close and reopen, each no earlier than the one before it by exact time. Either way the platform derives the status and closed date from the log’s last entry. When the source system’s dates contradict each other, such as a close dated before its open or a re-open with no close before it, fix them before sending: the platform refuses such a log with 400 at the entry it refuses, and a create then makes nothing. An entry dated today and sent without effectiveAt takes the current time; to load it at the start of its day instead, send that moment as effectiveAt with effectiveTimeKnown: false. A historical import should also leave eventReferenceId unset so the platform generates the Event ID. Load the claim’s existing number into a claim-number field in your configuration. See Event.

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. It is an ordinary Date value: { "date": "2026-08-15", "timezone": "America/New_York" }. timezone may be omitted and defaults to America/New_York.

The exact time

Every log entry also records the exact moment its action takes effect, in effectiveAt: a UTC timestamp to the second, such as 2026-08-15T19:05:33Z. Its day, read in the timezone of the entry’s effectiveOnDate, is that date, so Closed Date and the other claim dates stay plain dates.
  • Close and Re-open take an optional effectiveAt. Send a timestamp with an offset or Z, such as 2026-08-15T14:05:00-05:00, on the day of effectiveOnDate. A timestamp without an offset, or one on another day, returns 400.
  • An entry written without effectiveAt gets one: the current time when its effectiveOnDate is today in its timezone, otherwise the start of that day. An entry timed at the start of the day has effectiveTimeKnown: false.
  • The same applies to the entries of a log you send in full (on create, through Replace Event Open/Close History, or a generic PATCH), and to the entries the platform builds from openedOn and closedDate. Each entry may carry effectiveTimeKnown: false beside its effectiveAt when the time only stands in for one nobody knows.
  • Entries written before exact times existed have a placeholder, with effectiveTimeKnown: false: the start of their effectiveOnDate in its timezone, or one second after the entry listed before them when that one falls on the same day, and never later than an entry with a time listed after them on that day. Entries that share a day keep their order.
The claim dates follow exact times. openedOn is the date of the open with the earliest effectiveAt, and reopenedOn the date of the reopen with the latest; on a tie, the one listed last. 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 claim’s reopenedOn, although its date is the earlier one. previousClosedOn is the close the log lists just before that re-open. The log cannot run backwards. A close or re-open may not be earlier than the last entry already in the event’s log, compared by exact time, not by day: a close at 10 PM in Los Angeles can follow an open at 12:30 AM the next day in New York, and a close at 1 PM can’t follow an open at 2 PM the same day. An earlier one returns 409 (EventLifecycleDateOutOfOrder), and the message names both moments. A tie is allowed, and the log’s order breaks it. 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: the date alone would put the new entry at the start of the day, before it. Then the 409 says so, gives the earliest time allowed, and asks for effectiveAt. A log you send in full follows the same rule, entry by entry, with a 400 at the entry it refuses.

Editing the Closed Date

On a closed event, Closed Date (closedDate) stays editable — on the claim page, through a generic PATCH to /entities/event/{entityId}, or with the MCP tools — and an edit moves the log with it, so the status, the closed date and the log still agree:
  • The log’s last close moves to the new date; the date the close was entered is kept. If the log does not end in a close, one is added.
  • To give the close its exact time, add effectiveAt inside closedDate, a timestamp with an offset or Z on the new date in its timezone: { "date": "2026-09-12", "timezone": "America/New_York", "effectiveAt": "2026-09-12T15:20:00-04:00" }. The close takes that time, with effectiveTimeKnown: true; without it, the moved close is timed as an entry written without effectiveAt. The stored closedDate stays a plain date. A time on another day, or without an offset, returns 400, and so does a time inside a closedDate sent with eventOpenCloseHistory or on create.
  • The close may not be earlier than the event’s latest open or re-open, the step it follows, compared by exact time: an earlier one returns 409 (EventLifecycleDateOutOfOrder), and the message names both moments. A date sent without a time on the day of a later, timed open or re-open is asked for its time, as above. A later Re-open is then bounded by the edited close.
  • Clearing it on a closed event, or setting it on an open one, returns 400: re-open or close the event instead. Changing it on a closed event that has no log returns 400 too; give the event its log with Replace Event Open/Close History. Sending the date the event already has, in the same timezone and with no time or the close’s own time, is not an edit, and clearing a Closed Date left on an open event is accepted.
  • The same day in another timezone is an edit: the log’s last close moves to that timezone. So is the same day with another effectiveAt: the close is re-timed. A date sent without a timezone is in America/New_York.
  • A PATCH that sends eventOpenCloseHistory itself must send a complete, well-formed log, as the replace endpoint requires; the status and closed date follow its last entry, so such a PATCH can close or re-open the event.
  • Moving the log is a write of eventOpenCloseHistory: if your configuration gives that field a field write group, the edit needs that group, or returns 403 field-write-permission-required naming eventOpenCloseHistory.
Every write keeps the status, the closed date and the log in agreement. An event written before this rule can still disagree until its Closed Date or log is next written.

Endpoints

  • Close Event — status becomes closed, Closed Date is stamped with the date you send, and a close entry is appended to the log.
  • Re-open Event — status returns to open, Closed 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.
  • Replace Event Open/Close History (PUT /events/{eventId}/open-close-history) — replaces the whole log in one call, for historical imports and corrections. The status and closed date are re-derived from the log’s last entry.