Skip to main content

​
Overview

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.

​
Correlation

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