Migrating from Requests to Snapshots
The Member Request workflow is now deprecated in favor of using Member Snapshot
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 |
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. The Tracking API provides a unified field-level diff engine that spans in-flight changes through asynchronously processed carrier syncs.