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.
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
andgroup_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.
Updated 2 months ago