Members & Changes
Member Data
Data available for employees and dependents
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.
Most of the time you will not create members directly through Noyo. Instead, members will be created via snapshots or carrier syncs. Because of this, it will be important to understand member linking.
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”).
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”).
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_idandgroup_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 Noyoid. 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 |
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 Noyoid. 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 |
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 adependent_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
When available from the carrier, Noyo can return a premium amount that was billed to a member. Currently we can return premium amounts for Beam, with more carriers coming soon. Callers can query the API byemployee_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.