> ## 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 Transactions

<Warning>
  The Member Request workflow is now deprecated in favor of using [Member
  Snapshot](/docs/members/using-snapshots/using-snapshots)
</Warning>

Each member request (or snapshot) may contain multiple member transactions, which represent smaller sub-operations being carried out at carrier partners. For example, a single request that enrolls a new hire may result in two member transactions: one to add medical coverage at Carrier A, and a second to add dental and vision coverage at Carrier B.

In most cases, it's best to track the status of a member request or member snapshot, which is a combination of the statuses of individual transactions. A snapshot will not reach `complete` until all of the component transactions are complete. Noyo's transaction endpoints allow partners to track transaction statuses if they choose.

### Get Single Member Transaction

Returns the latest version of a single member transaction based on the ID provided.\
[Get Member Transaction](/api-reference/transactions/getmembertransaction)

### Get Member Transaction Status Details

Status Details are the processing history of a member transaction. This endpoint will return a list of all status details for a given transaction, as well as the `event_created` timestamp signifying when the transaction entered each status.

The possible values for the `status_detail` field are detailed below.

| Status Detail        | Description                                                                                                                                                   |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `noyo_accepted`      | Noyo confirms we have successfully received your transaction request and will begin processing.                                                               |
| `carrier_accepted`   | Noyo confirms the carrier has successfully received the transaction we've sent on your behalf.                                                                |
| `carrier_processing` | The transaction is currently being processed at the carrier.                                                                                                  |
| `carrier_completed`  | The carrier has confirmed the transaction was successfully fulfilled. Noyo will now have the changes from the carrier reflected in the dashboard and via API. |
| `noyo_verified`      | Noyo has completed round-trip confirmation for the member transaction. This occurs on the date that all changes from the transaction are effective.           |

Returns a list of all status details for a given transaction.\
[Get Status Details](/api-reference/transactions/status-detail/getstatusdetaillist)

#### Get Member Transaction Status Details Response

This endpoint will return only the most recent status for a given transaction, with the `event_created` timestamp of when the transaction transitioned into this state.

### Get Member Transaction Latest Status Detail

Returns the latest status detail for a given transaction.\
[Get Latest Status Detail](/api-reference/transactions/status-detail/getlateststatusdetail)

### Get All Member Transactions

Returns a list of all member transactions\
[Get Member Transactions List](/api-reference/transactions/getmembertransactionslist)

## Verified Member Transactions

Often member transactions are sent in advance and will become effective at a date in the future (e.g, a `new_hire` member request with a `hire_date` of today, but the coverage does not start until the first of next month). Noyo works with carriers to verify that transactions have taken effect as expected and will mark the member transaction as `verified` when applicable. The `verified` field is the [Unix time](https://en.wikipedia.org/wiki/Unix_time) at which the member transaction was verified. You can expect the following timelines for verification at most carriers:

| Transaction Type      | Timeline                                                                             |
| --------------------- | ------------------------------------------------------------------------------------ |
| New Hire              | On or shortly after the `effective_start_date` of the created individual enrollments |
| Termination           | On or shortly after the `last_day_of_coverage`                                       |
| Qualifying Life Event | On or shortly after the effective date of coverage changes                           |
| Open Enrollment       | On or shortly after the effective date of coverage changes                           |
| Demographic Change    | Immediately after completion of the member transaction                               |

Member transactions and snapshots in the `completed` status require no additional attention or action from you. Think of verified transactions as ones where we were able to do a successful double check that everything went as we expected.