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

# Track movement status

> Follow transfers, withdrawals, and deposits to completion using polling or webhooks.

Every movement can be followed two ways: poll the read APIs, or subscribe to webhooks for event-driven updates.

## Read APIs

| Movement   | Poll                                                                         |
| :--------- | :--------------------------------------------------------------------------- |
| Transfer   | `GET /v2/transfers`, or `GET /v2/transfers/{transferId}`                     |
| Withdrawal | `GET /v2/transactions`, or `GET /v2/transactions/{id}`                       |
| Deposit    | `GET /v2/transactions`, or list deposit attributions for pending attribution |

Transfers and withdrawals use different status vocabularies. Transfers move through `QUEUED`, `IN_PROGRESS`, `COMPLETED`, and `FAILED`. Withdrawals move through `NEEDS APPROVAL`, `INPROGRESS`, `SUCCESS`, `FAILURE`, `REJECTED`, and `EXPIRED`. See [Transfer](/knowledge-base/platform/developers/move-money/transfer) and [Withdraw](/knowledge-base/platform/developers/move-money/withdraw) for the full lifecycles.

## Webhooks

Subscribe to webhooks to receive updates as operations and transactions change state, instead of polling. For digital assets, delivery waits on on-chain confirmation, typically around two confirmations; USD events fire once the transfer or wire settles. See [Webhooks](/knowledge-base/platform/developers/webhooks/webhooks-overview).

### Correlate a webhook to its transaction

Webhook events are lightweight—each carries the identifier of the affected record, not its full detail. On receipt, fetch the record and inspect it:

<Steps>
  <Step title="Receive the event">
    A `deposit.*`, `transfer.*`, or `withdrawal.*` event arrives with the transaction identifier. See [Webhooks](/knowledge-base/platform/developers/webhooks/webhooks-overview) for the event catalog and payload fields.
  </Step>

  <Step title="Fetch the full record">
    Look it up with the matching read API: transfers via `GET /v2/transfers/{transferId}`; deposits and withdrawals via `GET /v2/transactions/{id}`.
  </Step>

  <Step title="Interpret the movement">
    Read `transactionType` (`DEPOSIT`, `WITHDRAW`, or `TRANSFER`) together with `sourceAddresses` and `destinationAddresses` to classify what happened and where the funds moved.
  </Step>
</Steps>

### Tell an internal deposit from an external one

An internal transfer between your own wallets lands as a `DEPOSIT` on the destination wallet, the same shape as a deposit from an outside sender. To distinguish them, compare the deposit's `sourceAddresses` against the addresses you manage (from `GET /v2/wallets` and the addresses API): a match means the funds came from one of your own wallets; otherwise the sender is external.

<Note>
  The transfers API identifies records by `transferId`, which isn't always a UUID. Match on the value exactly as returned rather than assuming a format.
</Note>

## Idempotency and retries

Provide an `idempotentId` per request so an interrupted call can be retried safely without double-spending. For status codes, rate limits, and cursor pagination, see [Handling errors, retries, and pagination](/knowledge-base/api-reference/errors-pagination).