> ## Documentation Index
> Fetch the complete documentation index at: https://docs.noyo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/docs/members/using-snapshots/using-snapshots) or carrier syncs. Because of this, it will be important to understand [member linking](/docs/groups/mapping/linking-members).

# 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](/api-reference/members/employees/getgroupemployee) based on `employee_id`
* [Get a single employee for a given group](/api-reference/members/employees/getgroupemployee), based on a combination of `employee_id` and `group_id`
* [Get all employees for a given group](/api-reference/members/employees/getgroupemployeelist), based on `group_id`. See below for filtering.
* [Get all employees associated with your organization](/api-reference/members/employees/getemployeelist), 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](/api-reference/members/employees/getgroupemployeelist) 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](/api-reference/members/employees/getemployeelist), 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](/api-reference/members/dependents/getdependent) with a `dependent_id`, or with a `dependent_id` and `employee_id` combination with the [Get a Single Dependent of Employee](/api-reference/members/dependents/getemployeedependent) endpoint.

You can also [fetch a list of dependents for a given employee](/api-reference/members/dependents/getdependentlist) 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](/api-reference/members/enrollments/getindividualenrollmentbygrouplist), [group enrollment](/api-reference/members/enrollments/getindividualenrollmentlist) (i.e., line of coverage), [employee](/api-reference/members/enrollments/getindividualenrollmentbyemployeelist), or [dependent](/api-reference/members/enrollments/getindividualenrollmentbydependentlist).

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](/docs/members/using-snapshots/using-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](/api-reference/members/premiums/getmemberpremiumsbyemployeeid) 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.