Skip to main content

​
What is a member snapshot?

Member snapshots are the way that all elections and ongoing member changes–like QLEs or demographic changes–are communicated to Noyo, regardless of carrier. Each member snapshot is a JSON payload that contains the full intended state of a covered family (the employee and all dependents). Noyo analyzes each snapshot, identifies whether any changes are being communicated, and transmits the necessary data to each relevant carrier. Because a snapshot represents the full state of a family, the content will be the same regardless of the type of changes being requested. You should make sure that every snapshot contains the maximum available information for each member, every time. For example, even though a carrier may not require volumes for life or disability coverage, each snapshot should include volume amounts (even when you are not intending to change these amounts). Every snapshot should include:
  • All demographic information for each family member
  • All coverages that are currently active, as long as they aren’t terminated
  • All coverages that are scheduled to become active in the future
  • All coverages that are being terminated with this request (terminated coverages only need to be referenced once, even if terminated in the future)
  • Any relevant event details that could affect processing (for example, if the request is being made for open enrollment)
Missing information can affect enrollments.If information stored by the Noyo system isn’t included in the snapshot, Noyo may not accept the request. This prevents accidental deletion of active enrollments or members, but means that you must be careful that your submissions align with existing Noyo data.Snapshots submitted with missing data can lead to unexpected outcomes and should be avoided. For instance, a request that attempts to terminate a family but leaves out a family member could lead to the request being rejected or the family remaining active. For that reason, Noyo will often reject a request which is missing a member we know is active in the carrier’s records.
See the full member snapshot format in our API reference. An additional set of detailed example snapshot payloads and responses is also available as part of our integration support.

​
When to send a member snapshot

​
Initial census

The first time you activate a carrier connection for a group, you’ll need to send an initial set of “census” snapshots. This establishes the member data in the Noyo system and allows us to populate the file (for Send connections) or run an initial comparison between your data and the carrier’s to find discrepancies (for Sync connections).

​
Ongoing snapshots

After the census, you should send a new snapshot each time an event in your system may trigger an update to a member. For example, an employee might log in to enroll as a new hire, add/change/waive coverages for themself and their family, then complete their session. At that point, your system would build a new snapshot which reflects the new state of the family and send it to Noyo, either in real time when the actions are taken or later with a periodic job that creates a new snapshot for any members with recent activity. It’s not necessary for your system to track exactly which fields or coverages members are changing; we will determine this when snapshots come in and pick out the changes that need to be sent to carriers. We also recommend sending snapshots for each group on a weekly cadence in addition to triggering snapshots immediately after changes. This helps us identify potential discrepancies faster and ensure that data stays aligned between your system and the carrier’s. These snapshots may not necessarily be tied to a particular member event in your system, but it’s still best practice to persist the most recent event reason(s) in these snapshots.

​
Rate limits

There is no formal rate limit for sending snapshots. However, multiple snapshot requests should not be sent concurrently for a single member, even with multiple auth tokens. Concurrent requests (within miliseconds of each other) for a single member may be rejected by Noyo.