Skip to main content

Group Data

The group object represents an insured group/employer that is managed by your organization and successfully connected to Noyo. Group, plan, and enrollment data is available when a group connection request for a Sync carrier is complete or when a Send group connection’s status is action_required. In general, you cannot edit group-level data through Noyo, with the exception of name, FEIN, DBA name, and SIC code. All other group level data, like location addresses or tax information, must be changed directly with the carrier.

Group basics

Create a group to get started. Get a Single Group to view details such as the name of the group, the EIN, and the SIC code of the company. To see all the groups managed with Noyo by your organization, you can Get a List of All Groups. You can search that groups list with the company query param. It allows searches based on the group’s name or dba_name values. Other helpful group data is available using the group’s ID:

Carrier configurations

Certain carriers have custom data for each group, such as billing information. Use the Get Group Carrier Configurations endpoint to retrieve any carrier-specific configuration data for a given group. This endpoint can be used to retrieve carrier-specific configuration data. Here are the options for this object:

Filter for a carrier’s group ID

You can use the combination of a carrier_id and a carrier_group_id to filter for a carrier-specific group ID. This ID will depend on the carrier, but it will generally be a unique identifier for the group from the carrier’s system.

Carrier syncs

Noyo regularly syncs–or retrieves–group data from any Sync carriers the group has coverage with to bring in the carrier’s version of the group. The Get Latest Audit endpoint returns metadata about the last group audit that was completed. If no group audits have been completed, the completed_at timestamp will be the timestamp of when the group was created and the carrier_ids array will be empty.

Plan and enrollment data

Enrollments

The enrollments object represents the each individual line of coverage (LOC) being offered by a specific group (e.g. medical, dental, vision). You can manage the following types of benefits through Noyo:
  • Accident
  • Accidental death and dismemberment (AD&D)
  • Cancer
  • Critical Illness
  • Dental
  • Hospital indemnity
  • Life
  • Long-term disability (LTD)
  • Medical
  • Short-term disability (STD)
  • Vision
Start by getting a list of all enrollments for a given group. This will return IDs, dates, and statuses for all the group’s enrollments. You can then use each enrollment ID to get a single group enrollment and its associated data in the future.

Plan data

The plans object represents a plan or benefit offered by a carrier to employee or dependent members of a group. You can use the group’s ID to get a list of all their plans, which returns IDs for each individual plan. You can also use a group plan ID to get details on a specific plan. Note that the response will be nested in a plan attribute. Different data is included in the response for each plan depending on its LOC. See below for specific data returned across all LOCs supported by Noyo and more detail on waiting periods.

Accident Plan Object

AD&D Plan Object

Cancer Plan Object

Critical Illness Plan Object

Dental Plan Object

Hospital Indemnity Plan Object

Life Plan Object

LTD Plan Object

Medical Plan Object

STD Plan Object

Vision Plan Object

Waiting periods

Each group plan may include one or more waiting period rules based on the information made available by the carrier. Each waiting period will always have a waiting_period_enrollment_type field. The waiting_period_enrollment_type determines when the waiting period is used: new_member applies to new members enrolling as new hires, current_member applies to existing members enrolling with a QLE, and rehire applies to previously active members re-enrolling as a rehire. Each waiting period will always have a waiting_period_rule field. This field is a general description of the waiting period rule, and determines which other fields will be present in the waiting period response. Some waiting period rules have a waiting_period_coinciding flag. This flag is relevant when the rule defines a specific date for starting coverage and the member waiting period may end on that date. For example, the waiting period rule may be ‘1st of month after hire date’ for a new member with a hire date of January 1st. When waiting_period_coinciding is true, the member would begin coverage immediately in the coinciding period, starting on January 1st. When waiting_period_coinciding is false, the member coverage would be pushed out to the following period starting February 1st.

Fixed Waiting Period Object

Fixed Coinciding Waiting Period Object

Variable Waiting Period Object

Variable Coinciding Waiting Period Object