> ## 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.
# COBRA Requests
The Member Request workflow is now deprecated in favor of [Member
Snapshot](/docs/members/using-snapshots/using-snapshots)
In general, {/* <> */}COBRA requests share most of the attributes of their non-COBRA equivalents. These requests should be used for all requests involving COBRA coverage. Using normal member requests will risk your request being rejected or not completed.
## COBRA Enrollment
The COBRA enrollment member request is used to add an existing employee, and optionally their dependents to multiple coverages at multiple carriers. This is for a continuation of benefits situation, when main line coverage either has already been terminated, or will be in conjunction with this member request.\
[COBRA enrollment member request](/api-reference/requests/cobraenrollmentmemberrequest)
### Termination Info
The `termination_info` block contains information about the termination of the employee prior to COBRA enrollment. If you have already sent a Termination Member Request for the employee the data from that request will be used. If you have not sent a Termination Member Request the data from this request will be used to terminate the member at the carrier.
| | | |
| ------------------ | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `reason`\* | string | Reason for employee termination of coverage. One of: `involuntary`, `job-eliminated`, `leave-of-absence`, `loss-of-eligibility`, `member-deceased`, `military-leave`, `voluntary` |
| `last_work_date`\* | string | ISO-8601 date string for last day of work of the terminated employee |
### The Coverages Object
The `coverages` array contains one entry for each carrier with which you would like to enroll or waive coverage. The `carrier_id` along with the schema of the `carrier_config` object will be provided by the Noyo team. You can reference the [Get carrier configuration by group list](/api-reference/groups/configurations/get-carrier-configuration-by-group-list) to get additional carrier-specific data. The `lines_of_coverage` object allows the following keys:
| Key | Description |
| -------------------- | -------------------------------- |
| `accident` | Accident |
| `add` | Accidental Death & Dismemberment |
| `cancer` | Cancer |
| `critical_illness` | Critical Illness |
| `dental` | Dental |
| `hospital_indemnity` | Hospital Indemnity |
| `life` | Life |
| `ltd` | Long Term Disability |
| `medical` | Medical |
| `std` | Short Term Disability |
| `vision` | Vision |
### Signature Date
Within each entry in the `coverages` array you can optionally specify a `signature_date`. The `signature_date` is the date when the employee or employer signed for the change to be made. If a `signature_date` is not provided we will communicate the date the member request was received by the Noyo system as the `signature_date` to the carrier.
| | | |
| ---------------- | ------ | --------------------------------------- |
| `signature_date` | string | ISO-8601 date string for signature date |
### Enrolling Members
You must provide an `enrolling_members` entry for each employee or dependent that is enrolling in coverage with the carrier. The `plan_id` field is optional in each action. If you do not specify a `plan_id`, we will try to automatically select an available plan for the member based on the current group plans. When the group has more than one eligible plan for a member, you will need to specify the `plan_id` in the request. Plan IDs can be retrieved using the [Get group plan list](/api-reference/groups/plans/get-group-plan-list) endpoint.
### Enrolling in `medical`, `dental`, `vision`, `accident`, `cancer` or `hospital_indemnity`
Medical, dental, vision, accident, cancer and hospital indemnity coverage do not require any information beyond the member information and the selected plan.
| | | |
| --------------- | ------ | --------------------------------------------------------------- |
| `id`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member adding coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique identifier of the group plan in Noyo |
### Enrolling in `life`, `add`, `std`, `ltd` or `critical_illness`
Life, AD\&D, STD, LTD and critical illness coverage also *optionally* accept `volume` parameter in dollars (e.g. \$50,000 should be sent as `50000`).
| | | |
| --------------- | ------- | --------------------------------------------------------------- |
| `id`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member adding coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique identifier of the group plan in Noyo |
| `volume`ΛΆ | integer | Elected volume for the type of coverage being selected |
### Waiving Members
You can provide a `waiving_members` entry for each employee or dependent that is waiving coverage with the carrier along with the `reason` for waiving the coverage. This information will be communicated with the carrier where applicable. If you did not capture this information and only have the `enrolling_members` information the API request will still succeed.
| | | |
| --------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member waiving coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique identifier of the group plan in Noyo |
| `reason`\* | string | Reason the member is waiving coverage. One of: `medi-cal`, `medicaid`, `no-coverage`, `other-cobra`, `other-employee-group`, `other-ind-off-exchange`, `other-ind-on-exchange`, `other-medicare`, `other-parent-group`, `other-spouse-group`, `retiree-coverage`, `tricare-coverage`, `va-coverage`, `voluntary-withdrawal` |
> Sample Request Result
```json theme={"system"}
{
"dental": [
{
"member_id": "72af10df-a8b3-46f1-a114-ac36d4b8a6ea",
"member_type": "employee",
"individual_enrollment_id": "ff033377-59e2-40df-8206-8cec3a725411"
},
{
"member_id": "165d4537-be5f-4744-8a97-a5b10fcb75b1",
"member_type": "dependent",
"individual_enrollment_id": "ff033377-59e2-40df-8206-8cec3a725411"
}
],
"vision": [
{
"member_id": "72af10df-a8b3-46f1-a114-ac36d4b8a6ea",
"member_type": "employee",
"individual_enrollment_id": "08f9e430-9686-4b07-9e2c-6b26b8133dc3"
},
{
"member_id": "165d4537-be5f-4744-8a97-a5b10fcb75b1",
"member_type": "dependent",
"individual_enrollment_id": "08f9e430-9686-4b07-9e2c-6b26b8133dc3"
}
]
}
```
Upon the successful completion of all the transactions in the member request, the `status` of the member request will be updated to `completed` and the `result` of the member request will be an object with a key for each coverage (e.g. `dental`, `vision`) and an array with the following:
| | | |
| ---------------------------- | ------ | ------------------------------------------------------------------------------------ |
| `member_id`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member for the member enrollment result. One of: `dependent`, `employee` |
| `individual_enrollment_id`\* | uuid | Unique identifier of the individual enrollment in Noyo created by the member request |
## COBRA Open Enrollment
The COBRA open enrollment member request is used to make changes to employees, dependents and COBRA coverages during the open enrollment period.\
[COBRA open enrollment member request](/api-reference/requests/cobraopenenrollmentmemberrequest)
The `coverages` array contains one entry for each carrier with which you would like to make changes to coverage. The `carrier_id` along with the schema of the `carrier_config` object will be provided by the Noyo team. You can reference the [Get carrier configuration by group list](/api-reference/groups/configurations/get-carrier-configuration-by-group-list) to get additional carrier-specific data. The `lines_of_coverage` object allows the following keys for COBRA open enrollment:
| Key | Description |
| --------- | ----------- |
| `dental` | Dental |
| `medical` | Medical |
| `vision` | Vision |
### Signature Date
Within each entry in the `coverages` array you can optionally specify a `signature_date`. The `signature_date` is the date when the employee or employer signed for the change to be made. If a `signature_date` is not provided we will communicate the date the member request was received by the Noyo system as the `signature_date` to the carrier.
| | | |
| ---------------- | ------ | --------------------------------------- |
| `signature_date` | string | ISO-8601 date string for signature date |
### Coverage Actions
Within each object inside of `lines_of_coverage` you may provide three different actions: `adding_coverage`, `removing_coverage`, and `modifying_coverage`. More information about each of these is below.
#### Adding Coverage
The `adding_coverage` action is used to add new coverage for a member with a carrier. You must provide an `adding_coverage` entry for each employee or dependent that is enrolling in coverage with the carrier along with the COBRA eligible `plan_id`. The `plan_id` can be retrieved by [selecting a valid plan from the group plans list](/api-reference/groups/plans/get-group-plan-list).
##### Adding `medical`, `dental`, or `vision` coverage
Medical, dental, and vision coverage do not require any information beyond the member information and the selected plan.
#### Removing Coverage
The `removing_coverage` action is used to remove coverage from a member with a carrier. The structure of the `removing_coverage` action is below:
| | | |
| --------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member removing coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique identifier of the group plan in Noyo |
| `reason`\* | string | Reason the member is removing or canceling coverage. One of: `medi-cal`, `medicaid`, `no-coverage`, `other-cobra`, `other-employee-group`, `other-ind-off-exchange`, `other-ind-on-exchange`, `other-medicare`, `other-parent-group`, `other-spouse-group`, `retiree-coverage`, `tricare-coverage`, `va-coverage`, `voluntary-withdrawal` |
#### Modifying Coverage
The `modifying_coverage` action is used to make changes to an **existing** coverage for a COBRA enrolled member / plan combination, given that the member already has COBRA coverage on that plan with the carrier. For example, you can use the `modifying_coverage` action to change the volume of coverage for a member's existing life or disability plan, or pass the same set of plans to remain on COBRA coverage with no changes.
##### Modifying `medical`, `dental`, or `vision` coverage
Medical, dental, and vision coverage do not require any information beyond the member information and the selected plan.
| | | |
| --------------- | ------ | ------------------------------------------------------------------ |
| `id`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member modifying coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique identifier of the group plan in Noyo |
### COBRA Open Enrollment Transactions
One or more COBRA open enrollment transactions will created based on the requested changes in the `coverages` array. For some carriers, there may be a single transaction including all of the requested changes, while other carriers may require separate transactions for each action type (i.e. one transaction per action per carrier).
#### COBRA Open Enrollment Member Transaction `completed` Result
Upon the successful completion of the transaction, the `status` of the member transaction will be updated and the `result` of the member transaction will be in the same format as the member request result.
## COBRA Qualifying Life Event
The COBRA qualifying life event member request is used to make changes to employees, dependents and COBRA coverages due to a qualifying life event.\
[COBRA qualifying life event member request](/api-reference/requests/cobraqualifyinglifeeventmemberrequest)
### The Event Object
Each COBRA Qualifying Life Event requires an `event` parameter in the body which provides information about the type of the event as well as the date of its occurrence. The schema for the `event` must follow this structure:
| | | |
| -------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `event_type`\* | string | Qualifying life event type. One of: `adoption`, `change_to_full_time`, `change_to_part_time`, `classifications_change`, `court_order`, `death`, `dependent_open_enrollment`, `divorce`, `foster_care`, `immigration_status_change`, `legal_guardian`, `lost_coverage`, `marriage`, `medicare`, `moved`, `newborn`, `offline_change`, `rate_changed`, `rehire`, `reinstatement`, `terminate_cobra` |
| `event_date`\* | string | ISO-8601 date string for qualifying life event date |
### The COBRA QLE Coverages Object
The `coverages` array contains one entry for each carrier with which you would like to make changes to coverage. The `carrier_id` along with the schema of the `carrier_config` object will be provided by the Noyo team. You can reference the [Get carrier configuration by group list](/api-reference/groups/configurations/get-carrier-configuration-by-group-list) to get additional carrier-specific data. For COBRA QLE requests, the `lines_of_coverage` object allows the following keys:
| Key | Description |
| --------- | ----------- |
| `dental` | Dental |
| `medical` | Medical |
| `vision` | Vision |
### Signature Date
Within each entry in the `coverages` array you can optionally specify a `signature_date`. The `signature_date` is the date when the employee or employer signed for the change to be made. If a `signature_date` is not provided we will communicate the date the member request was received by the Noyo system as the `signature_date` to the carrier.
| | | |
| ---------------- | ------ | --------------------------------------- |
| `signature_date` | string | ISO-8601 date string for signature date |
### Coverage Actions
Within each object inside of `lines_of_coverage` you may provide three different actions: `adding_coverage`, `removing_coverage`, and `modifying_coverage`. More information about each of these is below.
#### Adding Coverage
The `adding_coverage` action is used to add new coverage for a member with a carrier. You must provide an `adding_coverage` entry for each employee or dependent that is enrolling in coverage with the carrier. The `plan_id` field is optional in each action. If you do not specify a `plan_id`, we will try to automatically select an available plan for the member based on the current group plans. When the group has more than one eligible plan for a member, you will need to specify the COBRA eligible `plan_id` in the request. Plan IDs can be retrieved using the [Get group plan list](/api-reference/groups/plans/get-group-plan-list) endpoint.
#### Adding `medical`, `dental`, or `vision` coverage
Medical, dental, and vision coverage do not require any information beyond the member information and the selected plan.
#### Removing Coverage
The `removing_coverage` action is used to remove coverage from a member with a carrier. The structure of the `removing_coverage` action is below:
| | | |
| --------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member removing coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique identifier of the group plan in Noyo |
| `reason`\* | string | Reason the member is removing or canceling coverage. One of: `medi-cal`, `medicaid`, `no-coverage`, `other-cobra`, `other-employee-group`, `other-ind-off-exchange`, `other-ind-on-exchange`, `other-medicare`, `other-parent-group`, `other-spouse-group`, `retiree-coverage`, `tricare-coverage`, `va-coverage`, `voluntary-withdrawal` |
#### Modifying Coverage
The `modifying_coverage` action is used to make changes to an **existing** coverage for a COBRA enrolled member / plan combination, given that the member already has COBRA coverage on that plan with the carrier. For example, you can use the `modifying_coverage` action to change the volume of coverage for a member's existing life or disability plan, or pass the same set of plans to remain on COBRA coverage with no changes.
#### Modifying `medical`, `dental`, or `vision` coverage
Medical, dental, and vision coverage do not require any information beyond the member information and the selected plan.
| | | |
| --------------- | ------ | ------------------------------------------------------------------ |
| `id`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member modifying coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique identifier of the group plan in Noyo |
### COBRA Qualifying Life Event Member Request Result
> Sample Request Result
```json theme={"system"}
{
"dental": [
{
"member_id": "72af10df-a8b3-46f1-a114-ac36d4b8a6ea",
"member_type": "employee",
"individual_enrollment_id": "ff033377-59e2-40df-8206-8cec3a725411"
},
{
"member_id": "165d4537-be5f-4744-8a97-a5b10fcb75b1",
"member_type": "dependent",
"individual_enrollment_id": "ff033377-59e2-40df-8206-8cec3a725411"
}
],
"vision": [
{
"member_id": "72af10df-a8b3-46f1-a114-ac36d4b8a6ea",
"member_type": "employee",
"individual_enrollment_id": "08f9e430-9686-4b07-9e2c-6b26b8133dc3"
},
{
"member_id": "165d4537-be5f-4744-8a97-a5b10fcb75b1",
"member_type": "dependent",
"individual_enrollment_id": "08f9e430-9686-4b07-9e2c-6b26b8133dc3"
}
]
}
```
Upon the successful completion of all the transactions in the COBRA qualifying life event member request, the `status` of the member request will be updated to `completed` and the `result` of the member request will be an object with a key for each coverage (e.g. `dental`, `vision`) and an array with the following:
| | | |
| ---------------------------- | ------ | ------------------------------------------------------------------------------------ |
| `member_id`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member for the member enrollment result. One of: `dependent`, `employee` |
| `individual_enrollment_id`\* | uuid | Unique identifier of the individual enrollment in Noyo created by the member request |
### COBRA Qualifying Life Event Transactions
One or more COBRA qualifying life event transactions will be created based on the requested changes in the `coverages` array. For some carriers, there may be a single transaction including all of the requested changes, while other carriers may require separate transactions for each action type (i.e. one transaction per action per carrier).
#### COBRA Qualifying Life Event Member Transaction `completed` Result
Upon the successful completion of the transaction, the `status` of the member transaction will be updated and the `result` of the member transaction will be in the same format as the member request result.
## COBRA Termination
The COBRA termination member request is used to remove an employee and their dependents from COBRA coverage at all carriers. The `cobra_termination_date` is the date on which the COBRA coverage should be terminated.\
[COBRA termination member request](/api-reference/requests/cobraterminationmemberrequest)
### Signature Date
Within the COBRA termination request body you can optionally specify a `signature_date`. The signature\_date is the date when the employee or employer signed for the change to be made. If a `signature_date` is not provided we will communicate the date the member request was received by the Noyo system to the carrier as the `signature_date`.
### COBRA Termination Transactions
A COBRA termination transaction is created for each carrier that the employee and dependents have coverage with a type of `carrier_cobra_termination`.
### Carrier COBRA Termination Result
The result of the `carrier_cobra_termination` member transaction will include the last day that the members are covered at the carrier. The individual enrollments for the carrier will also be updated with a new status of `terminated`.
> Sample Transaction Result
```json theme={"system"}
{
"last_day_of_coverage": "2018-02-01"
}
```