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

# Migrating from Requests to Snapshots

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

In migrating from Member Requests to Member Snapshots, it's important to understand the concepts that govern both integrations, along with a few key differences.

### Member Request vs Snapshot Status

As with Member Requests, Member Snapshots have a high-level status field discussed here. The statuses used in Member Requests are available on Snapshots with generally the same meaning, and there are a few statuses new to Snapshot.

| Member Request | Member Snapshot       |
| -------------- | --------------------- |
| processing     | submitted, processing |
| completed      | completed             |
| failed         | failed                |
| canceled       | canceled              |
| (none)         | replaced              |

<br />

### Field-level change tracking

Member Request transactions include a `body` field which enumerates all of the changes included. Because Snapshots are fundamentally decoupled from prescribed changes, and especially because in-flight changes can span successive Snapshots, this works differently.

The best way to track the status of in-flight changes is via the Tracking API, which enumerates all fields that currently differ between the platform's expressed intended state and the respective carrier states.

In short, the successor for a request's `body` is a new endpoint, which is fully detailed [here](/docs/members/tracking/the-tracking-api). The Tracking API provides a unified field-level diff engine that spans in-flight changes through asynchronously processed carrier syncs.