A member is any employee or dependent enrolled in insurance. Our endpoints are structured to deliver employee and dependent data independently.

Member data is sourced from the regular data syncs we perform with Sync-level carriers, or it is submitted via member snapshots for Send-level carrier connections.

Employee data

The employee object represents an employee within a group. It contains personal information about the employee including name, address, and contact info as well as employment-related information like salary, occupation and employment status.

Getting employees

You can get employee data in several different ways, including via large, filterable lists of employees.

Get a single employee based on employee_id
Get a single employee for a given group, based on a combination of employee_id and group_id
Get all employees for a given group, based on group_id. See below for filtering.
Get all employees associated with your organization, regardless of group. See below for filtering.

Filtering Employees in a Group

There may be some cases where you wish to find a specific employee in a group, but do not know their Noyo id. We provide a way to filter your employee list for a given group via query parameters. The following parameters are accepted by the API in the query string:

Object	Type	Description
`date_of_birth`	date	ISO-8601 date string for the date of birth of the employee to be filtered on
`first_name`	string	First name of the employee to be filtered on
`last_name`	string	Last name of the employee to be filtered on
`name`	string	A name search for all name fields for the employee to be filtered on

The filtering is not case-sensitive and it does not require an exact match on the value (e.g. searching for "ann" will match against "Ann" as well as "Annie").

Filtering All Employees

There may be some cases where you wish to find a specific employee across all of your groups, but do not know their Noyo id. We provide a way to filter your employee list via query parameters. The following parameters are accepted by the API in the query string:

Object	Type	Description
`date_of_birth`	date	ISO-8601 date string for the date of birth of the employee to be filtered on
`first_name`	string	First name of the employee to be filtered on
`last_name`	string	Last name of the employee to be filtered on
`name`	string	A name search for all name fields for the employee to be filtered on

The filtering is not case-sensitive and it does not require an exact match on the value (e.g. searching for "ann" will match against "Ann" as well as "Annie").

Dependent data

The dependent object represents an employee's dependent. It contains personal information about the dependent including name, address, and contact info along with the dependent's relationship to the employee.

Getting dependents

You can get dependent data directly with a dependent_id, or with a dependent_id and employee_id combination with the Get a Single Dependent of Employee endpoint.

You can also fetch a list of dependents for a given employee using the employee's employee_id.

Individual enrollments

Each member has a separate Individual Enrollment for each coverage type they are enrolled in or have waived. You can get a list of Individual Enrollments for each group, group enrollment (i.e., line of coverage), employee, or dependent.

Individual enrollments are a rich source of data, containing fields like COBRA enrollment, coverage start and end dates, volume information where applicable, and carrier-specific configurations.

If you are managing member changes through Noyo, you will be manipulating individual enrollments by sending member snapshots that update coverage.

Member premiums

Noyo can return a premium amount that was billed to a member for coverage with a carrier.

Callers can query the API by employee_id to retrieve a list of member premiums associated with the employee and their family unit. The size of the response list will depend on the granularity of data made available by the carrier.

For example, if an employee is enrolled in dental and vision coverage and we know the exact cost split between each line of coverage, the response list would contain two member premium records, one with the dental amount and a single billed_members entry for the employee + dental plan, and one with the vision amount and a single billed_members entry for the employee + vision plan.

On the other hand, if we only know the total combined cost for both coverages, the response list would contain one member premium record with the total amount and two billed_members entries, one for the employee + dental plan and one for the employee + vision plan.