Skip to main content

​
Overview

EndpointWhoDestination
POST /api/v1/auth/transfers/p2pAuthenticated userAnother platform user (to_user_id or platform to_address)
POST /api/v1/auth/transfers/p2p/externalSameExternal chain address (must not be a linked platform wallet of another user in a way that violates validation rules)
POST /api/v1/auth/transfers/b2bVendor / subvendor / adminAnother vendor (to_vendor_id)
POST /api/v1/auth/transfers/b2b/externalSameExternal 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 or ethereum.
  • 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).

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