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

# Transfers (P2P and B2B)

> USDT Transfers Between Users, External Addresses, and Vendors/Merchants with Optional Pricing Snapshots

## Overview

| Endpoint                                   | Who                    | Destination                                                                                                               |
| ------------------------------------------ | ---------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `POST /api/v1/auth/transfers/p2p`          | Authenticated user     | Another **platform user** (`to_user_id`, platform `to_address`, or numeric wallet `to_alias`)                             |
| `POST /api/v1/auth/transfers/p2p/external` | Same                   | **External** chain address (must not be a linked platform wallet of another user in a way that violates validation rules) |
| `POST /api/v1/auth/transfers/b2b`          | Vendor/subvendor/admin | Another **vendor** (`to_vendor_id`)                                                                                       |
| `POST /api/v1/auth/transfers/b2b/external` | Same                   | **External** address (B2B multisig rules apply)                                                                           |

List and inspect: **`GET /api/v1/auth/transfers`**, **`GET /api/v1/auth/transfers/{id}`**, pricing snapshot: **`GET /api/v1/auth/transfers/{id}/pricing`**.

## Request Body (Common)

* **`amount`** - USDT string, must be positive.
* **`network`** - `tron`, `ethereum`, or `solana`.
* **`from_wallet_id`** - Optional. Defaults to the user’s default wallet for that network.

P2P requires a **platform-operated** sender wallet eligible for transfers (as determined when the wallet was created or linked).

## Wallet Aliases

Every platform wallet has a globally unique numeric **`alias`** in wallet API responses. Existing wallets are backfilled and newly created custodial, external, and multisig wallets receive an alias automatically.

For an internal P2P transfer, provide exactly one recipient identifier:

* **`to_user_id`** - Resolves the recipient’s default wallet for the requested network.
* **`to_address`** - Uses a registered platform wallet address.
* **`to_alias`** - Uses the specific platform wallet identified by its numeric alias. Its network must match the request.

Resolve an alias before presenting transfer confirmation with **`GET /api/v1/auth/wallet/alias/{alias}`**. Aliases are not reused after a wallet is soft-deleted.

## P2P Idempotency

Send an optional **`Idempotency-Key`** header (maximum 128 characters) on both P2P endpoints. Generate a new unique key for each intended transfer and reuse that key only when retrying the same request.

* A retry returns the original transfer and **`idempotent_replay: true`** without submitting another blockchain transfer.
* Reusing the key with a different request payload returns **`409 Conflict`**.
* Keys are scoped to the authenticated sender across internal and external P2P transfers.
* Requests without the header retain non-idempotent behavior.

## Optional Pricing (Same Rule on All Four POST Transfer Routes)

If you send **any** of the pricing fields, you must send **all** of:

* `pricing_profile_id`
* `fx_rate_quote_id`
* `fiat_currency`
* `fiat_amount_equivalent` (positive decimal string)

The profile and quote **`flow_type`** must match: **`p2p`** for P2P routes, **`b2b`** for B2B routes. Asset, fiat, and network must align with **`buildPricingSnapshot`** validation.

## B2B and Multisig

B2B **from** wallets must be registered as **multisig**. What happens next depends on how the wallet was provisioned:

* **Platform-Managed Multisig** - Transfers may **complete with `200`** once internal policy checks pass. The **`transfers`** resource reflects status and any settlement references returned by the platform.
* **Collaborative Signing** (TRON or Ethereum configurations that require co-signatures on-chain) - The API may return **202** with **`proposal_id`**. Signers use **`GET /api/v1/auth/multisig/proposals/{id}`** and **`POST .../confirm`**. See [Multisig wallets](/guides/multisig-wallets).

## Correlation

Successful transfer responses may include **`correlation_id`** and the **`X-Request-ID`** header for support and logging.