Member snapshots are the way ongoing member changes, like QLEs or demographic changes, are communicated to Noyo. 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 any changes represented in the snapshot, 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.
We suggest that you send a new snapshot each time an event in your system triggers updates to a member. For example, an employee might log in to enroll as a new hire; add, change, or waive coverages for themself and their family; then complete their session. At that point, your system would build a new snapshot which reflects all of the member's recent changes and send it to Noyo, either in real time when the changes are submitted, or later with a periodic job that creates a new snapshot for any members with recent updates.
There is no formal rate limit for sending snapshot requests. However, multiple snapshot requests should not be sent concurrently for a single member, even with multiple auth tokens. Concurrent requests for a single member may be rejected by Noyo or by our carrier partners.
Unlike many EDI connections, it’s not necessary to send recurring daily or weekly snapshots for every single member, including those without any changes. It’s also not necessary for your system to track exactly which fields or coverages are changing across each snapshot.
Updated 19 days ago
Learn what happens in the lifecycle of each member snapshot