Each member snapshot should include a block describing the event(s) associated with the member’s activities in your system. During onboarding, you’ll map your system’s member flows/options to Noyo’s events.
If we detect that a member snapshot contains changes to coverage and send those changes to the carrier, they’re more likely to be processed quickly and successfully if they are associated with an event. Though events are not always required, it’s best practice to send them any time you have them.
An event can be tied to a specific enrollment in the snapshot payload, which means it’s possible to send multiple events in a single snapshot. For instance, a snapshot could remove spousal coverage due to a divorce event at the same time that child coverage is added due to an adoption event. You should plan to include the last 60 days’ worth of events in each snapshot for a member, adding new events when they occur. Each event block includes an event date, reason, type, and id. See the member snapshot API reference for full detail. Importantly, the event date should always reflect the actual date of the relevant event. Sending other dates for events could cause denied coverage or unexpected coverage dates. See each event type below for details. 
"events": [
    {
      "date": "2022-01-01",
      "id": "1",
      "reason": "open_enrollment",
      "type": "coverage"
    }
  ]
If multiple event reasons could be associated with a single enrollment for a member, select the single most relevant event (such as open_enrollment). This will rarely impact processing.
Events are required for all snapshots containing coverages with Beam Benefits and/or Principal Fianancial Group.

​
Open enrollment events

An open_enrollment reason is highly recommended for any member snapshots containing selections made on or around the group’s Open Enrollment period. Many carriers process open enrollments differently from other changes, and omitting this reason can cause major delays. For open_enrollment events, the event date is the effective date of the group’s Open Enrollment, not the date when the member elects coverage.

​
Termination events

Most event reasons can be sent with any valid snapshot payload. The only exception is termination events, where Noyo requires that an employment termination date is also included in the snapshot.

​
Event reasons

The following are the most common event reasons, but there is a wider variety available if you require them for your system (see the API reference for the full list). 
ValueDescription
cobra_enrollmentUsed when enrolling members in COBRA coverage. See the COBRA section for more detail.
cobra_terminationUsed when terminating members from COBRA coverage. See the COBRA section for more detail.
demographic_changeUsed for demographic or employment data changes that do not impact coverage eligibility.
new_hireUsed for coverage decisions being made after being hired.
open_enrollmentUsed for coverage decisions made during the group’s open enrollment.
terminationUsed for most cases of employment termination. Voluntary/involuntary terminations are generally treated identically. In most cases of termination, the event date/termination date is equal to the last day of work for the member.
QLEs
adoptionApplies in the event that a member is looking to either add or remove coverage as a result of an adoption.
change_to_full_timeOften tied to benefit class or time status changes.
change_to_part_timeOften tied to a reduction of hours or a benefit class change.
deathApplicable to employee or dependent deaths and can be passed when adding or removing coverage due to death. Sending this is useful clarification in survivorship scenarios.
disability_status_changeUsed when adding or removing coverage due to changes in disability status.
divorceThis applies in the event that a member is looking to either add or remove coverage as a result of a divorce.
immigration_status_changeRefer to cases in which the spouse becomes newly eligible for coverage (e.g., by obtaining legal resident status) and is then added to member’s coverage.
lost_coverageUsed when a member is losing coverage for a reason not otherwise specified in this list. For instance, when adding someone to coverage due to lost coverage elsewhere and also when removing them from coverage.
marriageApplies in the event that a member is looking to either add or remove coverage as a result of a marriage.
movedMost often used when an address change makes someone either eligible or ineligible for coverage.
newbornApplies in the event that a member is looking to either add or remove coverage as a result of the birth of a child.
rehireWhen member is being added back to coverage after being hired again at a company where they were previously employed. Many carriers will not issue coverage promptly if rehires are sent as generic new hires, see Special Cases for full details.
reinstatementWhen a member is being added back to coverage as if they had never been terminated. Reinstatements differ from rehires, see Special Cases for full details.
retirementUsed to send coverage changes made in connection with retirement.