Depending on your needs, there are several ways to get and track the status of snapshots and their processing. Each is available via API, webhooks, and in Command Center.
  • Most general: Snapshot Status
  • Per-carrier validation and fulfillment: Snapshot Fulfillment Summary
  • Field-level tracking and diffing for enrollment changes: Tracking API

​
Snapshot Status

As Noyo processes the requested changes, you can periodically poll for status by sending a call to get a single snapshot. This endpoint returns a copy of one member snapshot, including the current status and the full contents of what was submitted. You can also get data about all snapshots for a given group with the group snapshots endpoint. This endpoint returns a paginated list of snapshot records associated with employees in a group. Each result in the list contains metadata about the snapshot request, including the unique ID and the associated employee ID, but not the complete snapshot payload. Results will default to descending order by date created, so the most recently created snapshots will be in the first page of results. This endpoint also supports an optional employee_id query param to filter all snapshots for a specific employee. When Noyo has finished making all requested changes at the carrier, the status of the member snapshot will change to completed. For changes going to Send carriers, the status will be completed once the file has been sent. If a member snapshot contains changes for both Sync and Send carriers, the Sync transactions will be completed first but the snapshot will only move to completed when the file has been sent. Member snapshots can have one of five statuses:
StatusDescription
submittedThe member snapshot has been submitted to Noyo and we have run initial processing and validation.
processingWe are identifying transactions and queuing them up to send to the right carrier(s) or there are still transactions contained in this snapshot that are being processed by the carrier(s).
completedAll member transactions have been completed by the Sync carrier or the file has been sent to the Send carrier.
canceledThe request was canceled and no changes have been sent to the carrier.
replacedIf the member snapshot was overridden by a subsequent snapshot while in the processing status, we will update the status to replaced and no longer attempt to fulfill this snapshot.
The replaced status applies to snapshots which were in progress, but were not completed before a new snapshot was received for the same employee. Noyo will only try to process and confirm the latest snapshot received, on the assumption that the latest snapshot contains the most up-to-date information. When the snapshot status is completed, Noyo schedules the second of our round-trip confirmation checks, which queries the carrier’s system on the change’s effective date to ensure that it still happens as expected.

​
Snapshot Fulfillment Summary

Many snapshots have information and enrollments that span multiple carriers. Whenever possible, Noyo does not block well-formed snapshots from processing at Carrier A if there are issues with the input(s) for Carrier B. These mechanics ensure a fast, accurate fulfillment process but introduce nuance in the idea of a snapshot’s “status.” Here are two examples of scenarios where the overall snapshot status may not be particularly useful:
  • There are blocking issues for one carrier but not another The provided body has validation issues that only affect one of the carriers but don’t affect another (e.g. omitted enrollments)
  • One or more carriers are Send For example, a snapshot’s updates have been sent to three carriers but the fourth is a Send carrier, meaning the update is scheduled for the future but not yet sent
To get the per-carrier status of a snapshot, you can use Snapshot Fulfillment Summary. This field includes an array of summary objects; one per carrier in the snapshot. This field will be included in the API response on the successful creation of a snapshot. As Noyo processes the requested changes, you can periodically poll for updates to Fulfillment Summary by sending a call to get a single snapshot. Corresponding webhooks are also available. 
{
    "status": "processing",
    "fulfillment_summary": [
        // one per carrier
        {
            "carrier_id": "<Beam ID>",
            "status": "sent", // terminal state
        },
        {
            "carrier_id": "<Guardian ID>",
            "status": "invalid", // for invalid data, instead of 422
            "errors": ["<error message>"] // provide errors
        },
        {
            "carrier_id": "<Cigna ID>",
            "status": "scheduled", // for Send
            "next_transmission": "<timestamp>" // for Send
        }
    ]
}
This example can be read as “The Beam updates were sent, the Cigna ones scheduled, and the Guardian ones had a validation issue that needs to be fixed.” This field will be included in the API response on the successful creation of a snapshot, along with subsequent calls to get the snapshot. The fulfillment summary items are updated as processing happens, and stop updating once they reach a state of sent, invalidor replaced. Because Snapshot Fulfillment Summary includes one object per carrier, it won’t include any field-level granularity or discrepancy information. It also won’t update with the results of round-trip confirmation. For that level of detail, use the Tracking API.
Fulfillment Summary StatusDescription
processingWe are identifying changes and queuing them up to send to the right carrier(s).
sentAll changes for a given carrier have been sent successfully.
invalidWe have identified an issue with the snapshot data and were unable to transmit changes to a carrier. Some errors will be detected immediately (such as formatting and missing data errors) while others will begin in processing and move toinvalidwhen the error is detected.
scheduledAll changes that must be included on a scheduled transmissions are queued and ready.
no_changesNo changes identified from the snapshot for the carrier.
replacedProcessing changes have been overridden by a subsequent snapshot.

​
Tracking

For live, detailed, field-level information, use the Tracking API. When you send a snapshot, Noyo calculates the diff from the previous snapshot to derive which changes need to be made with each carrier. That may be adding an enrollment or dependent or changing an address. Oftentimes it’ll be many of them across multiple carriers. For each change, a difference is created and exposed in the Tracking API. Differences are automatically de-duplicated and are associated with all snapshots that include the change before it’s reflected in the carrier system. When that change is made at the carrier, regardless of where it’s confirmed, it is resolved. If the process of making the change is completed (usually a transaction, which is discussed below), but the carrier system still does not correctly represent the change, the difference is escalated from change to discrepancy. Tracking is particularly useful for highlighting situations where a change was mostly fulfilled, but with a field-level discrepancy, such as when an enrollment is added but with an effective date 15 days later than requested; or when the requested volume requires evidence of insurability (EOI) and the issued volume is lower. In these cases, the pending change of “adding enrollment” will resolve, but a new discrepancy for the specific field will be opened. This functionality is unmatched in the industry. If you require (or desire) field-level tracking and confirmation, you may alternatively be considering your own logic to compare snapshots against the member data endpoints. Here we explain the advantages of using Tracking rather than building your own logic.

​
Transactions (Legacy)

Each snapshot request may contain multiple member transactions, which represent smaller sub-operations being carried out at carrier partners. Particularly when migrating from Member Requests, it’s important to note that Noyo does not recommend using transactions to track changes or perform confirmations. Read more here.