--- title: "Get transfer" method: GET path: "/api/v2/{coin}/wallet/{walletId}/transfer/{transferId}" tags: ["Transfer"] --- # Get transfer `GET /api/v2/{coin}/wallet/{walletId}/transfer/{transferId}` A transfer is a wallet specific object. Each transfer will only output the respective wallet id which the transfer is associated with. If there is a transaction between two BitGo wallets, then two transfers will be created, one for wallet A, and one for wallet B. Transfer A will only annotate the walletId on entries where the address belongs to wallet A. Transfer B will only annotate the walletId on entries where the address belongs to wallet B. **Go Account / OFC transfers (front/backing transfer model):** For Go Account (OFC) wallets, a withdrawal is represented as two transfers: 1. **Front transfer** — the record returned by this endpoint. Its `txid` and `normalizedTxHash` hold an internal BitGo front-transfer hash (e.g. prefixed with the OFC coin identifier). This value does **not** appear on any block explorer. 2. **Backing transfer** — the actual on-chain transaction that settles the withdrawal. The on-chain transaction hash is stored in the front transfer's `metadata` array under the key `onChainTxId`. When reconciling a Go Account withdrawal against an on-chain explorer or an external ledger, use `metadata[].onChainTxId` rather than the top-level `txid`. The `onChainTxId` entry is absent while the transfer is in state `signed`; it is populated once the transfer reaches state `confirmed`. Poll until `state === 'confirmed'` before reading this field. For standard `ofc_deposit` transfers (non-lightning) the top-level `txid` and `metadata[].onChainTxId` are identical. For OFC lightning deposits the payment hash is stored under `metadata[].lightningPaymentHash` instead; `onChainTxId` is not present on lightning deposits. See the `subType` field for whether a transfer is an `ofc_withdrawal`, `ofc_deposit`, `ofc_book_transfer`, `ofc_stake`, or `ofc_unstake`. ## Path parameters - `coin` string, required — A cryptocurrency or token ticker symbol. - `walletId` string, required - `transferId` union, required - string - string — The on-chain transaction id. **Go Account / OFC wallets:** For `ofc_withdrawal` transfers the top-level `txid` (and `normalizedTxHash`) is the internal front-transfer hash, not the on-chain transaction hash. The on-chain hash is available in `metadata[].onChainTxId` once the transfer reaches state `confirmed`. For standard `ofc_deposit` transfers (non-lightning) all three values are identical. For OFC lightning deposits the payment hash is in `metadata[].lightningPaymentHash`; `onChainTxId` is absent. ## Query parameters - `includeTxRequestCreatedDate` boolean ## Response `200` OK - AnnotatedTransferWithInputsOutputs - `coin` string, required — A cryptocurrency or token ticker symbol. - `id` string, required - `wallet` string, required - `enterprise` string - `txid` string, required — The on-chain transaction id. **Go Account / OFC wallets:** For `ofc_withdrawal` transfers the top-level `txid` (and `normalizedTxHash`) is the internal front-transfer hash, not the on-chain transaction hash. The on-chain hash is available in `metadata[].onChainTxId` once the transfer reaches state `confirmed`. For standard `ofc_deposit` transfers (non-lightning) all three values are identical. For OFC lightning deposits the payment hash is in `metadata[].lightningPaymentHash`; `onChainTxId` is absent. - `normalizedTxHash` string — A normalized form of `txid` used for deduplication. For most coins this is identical to `txid`. For account-model coins (e.g. ETH and its tokens) it may differ from `txid` when the transaction is regenerated. For lightning transfers, `normalizedTxHash` is identical to `txid` (no transformation is applied). **Go Account / OFC withdrawals:** Like `txid`, this field holds the internal front-transfer hash, not the on-chain hash. Use `metadata[].onChainTxId` for the on-chain transaction hash. - `txidType` 'transactionHash' | 'blockHash' — The type of the transaction id - `height` integer, required — The height of the block this Transfer was confirmed in (999999999 if unconfirmed) - `heightId` string — The unique height id of the block - `date` string, date-time, required — The date this Transfer was last updated - `confirmations` integer, required — The number of blocks that have been confirmed since this Transfer's block was confirmed - `type` 'send' | 'receive', required — Defines whether or not this Transfer was sent or received by the user - `value` integer — The total value (in base units) sent by this Transfer (may be approximate for ETH and other coins where amounts in base units can exceed 2^53 - 1) - `valueString` string, required - `intendedValueString` string - `baseValue` integer — The value (in base units) sent by this transfer, excluding network fees. BitGo is deprecating this field in the future. Instead, use baseValueWithoutFees. - `baseValueString` string - `baseValueWithoutFees` integer — The value (in base units) sent by this transfer excluding network fees. - `baseValueWithoutFeesString` string - `feeString` string — The Transfer's fee (in base units) represented as a String - `payGoFee` integer — The Transfer's BitGo fee (in base units) - `payGoFeeString` string — The Transfer's BitGo fee (in base units) represented as a String - `usd` number, required — The amount of USD of this Transfer (will be negative if it's a send) - `usdRate` number, required — The USD price at the time this Transfer was created - `state` 'confirmed' | 'failed' | 'initialized' | 'pendingApproval' | 'rejected' | 'removed' | 'replaced' | 'signed' | 'unconfirmed', required — The state of the transfer. Includes the following: - `confirmed`: The transfer is confirmed on chain. - `failed`: BitGo failed to confirm the transfer on chain. You must retry the transaction. - `initialized`: The initial state when creating a transfer. - `pendingApproval`: The transfer requires admin approval to proceed. - `rejected`: The transfer was rejected by an admin. - `removed`: A network re-org occurred, causing the confirmed transfer to be removed from the blockchain. - `replaced`: The transfer was stuck due to having a low fee and was replaced by a new transfer with a higher fee. - `signed`: The transfer was approved by an admin (if required) and then signed by BitGo. - `unconfirmed`: The signed transaction was sent to the network, and is pending on-chain validation. - `tags` Id[], required — The tags to be used on this Transfer (used in Policies) - `history` object[], required — An audit log of events that have happened to the Transfer during its lifecycle - `date` string, date-time — The date of this history object - `user` string - `action` 'created' | 'signed' | 'unconfirmed' | 'confirmed' | 'approved' | 'commented' | 'removed' | 'failed' | 'rejected' - `comment` string — If this history object is of action `commented`, this is the comment from the user - `comment` string, required — A comment from the user - `vSize` integer — The size of the transaction - `coinSpecific` object, required — Transfer fields specific to each coin type - `sequenceId` string — A `sequenceId` is a unique and arbitrary wallet identifier applied to transfers and transactions at creation. It is optional but highly recommended. With a `sequenceId` you can easily reference transfers and transactions—for example, to safely retry sending. Because the system only confirms one send request per `sequenceId` (and fails all subsequent attempts), you can retry sending without the risk of double spending. The `sequenceId` is only visible to users on the wallet and is not shared publicly. - `consolidateId` string - `txRequestId` string — Associated transaction request ID - `goStakingRequestId` string — Associated GO staking request ID - `subType` 'ofc_withdrawal' | 'ofc_deposit' | 'ofc_unstake' | 'ofc_stake' | 'ofc_book_transfer' — Transfer subtype - `feeCoin` string — The coin used to pay the fee (for cross-chain transactions) - `instant` boolean — Whether this is an instant transaction - `instantId` string — The instant transaction ID if applicable - `isFee` boolean — Whether this transfer represents a fee - `isReward` boolean — Whether this transfer represents a staking reward - `isUnlock` boolean — Whether this transfer represents an unlock operation - `metadata` object[] — Key-value pairs carrying additional metadata about the transfer. The same key may appear more than once. Known keys (alphabetical). This list reflects all keys defined in the current server release; additional keys may be added in future releases without a breaking-change notice. - `backingTransferBroadcastTimestamp` — Timestamp (ISO 8601) at which the backing on-chain transaction was broadcast to the network. - `lightningPaymentHash` — **(OFC lightning transfers only)** The Lightning Network payment hash for the transfer. Present on both `ofc_withdrawal` and `ofc_deposit` lightning transfers; for `ofc_deposit` lightning transfers this key is used instead of `onChainTxId`. - `onChainTxId` — **(Go Account / OFC non-lightning transfers only)** The on-chain transaction hash of the backing transfer. For `ofc_withdrawal` transfers this key is absent while the transfer is in state `signed`; it is populated once the transfer reaches state `confirmed` (i.e. once the backing on-chain transaction is confirmed). Poll until `state === 'confirmed'` before reading this field. Use this value — not the top-level `txid` — when reconciling against a block explorer or external ledger. For standard `ofc_deposit` transfers (non-lightning) this value equals the top-level `txid`. - `replacedBy` — Transfer ID of the transfer that replaced this entry. - `replaces` — Transfer ID of the transfer this entry replaces. - `reversedBy` — Transfer ID of the transfer that reversed this entry. - `reverses` — Transfer ID of the transfer this entry reverses. - `rtId` — Internal routed-transaction ID linking a front transfer to its backing Go Account routed transaction. - `stablecoinTxType` — Transaction type for stablecoin transfers (e.g. `mint`, `reward`, `burn`). - `tokenizationUniquenessId` — **(Tokenization withdrawals only)** Internal identifier used to prevent double-spends on a tokenization withdrawal. Derived from the tokenization order ID; not guaranteed to equal the order ID in rare same-merchant/same-amount/same-instant collisions. - `key` string — The metadata key name. See the `metadata` array description for documented values. Additional keys may be present. - `value` string - `sendAccounting` object[] — Accounting breakdown for send transactions - `type` string - `amountString` string - `nOuts` integer - `amount` integer - `id` string - `createdTime` string, date-time — The time this transfer was created - `approvedTime` string, date-time — The time this transfer was approved - `rejectedTime` string, date-time — The time this transfer was rejected - `signedTime` string, date-time — The time this transfer was signed - `unconfirmedTime` string, date-time — The time this transfer became unconfirmed - `confirmedTime` string, date-time — The time this transfer was confirmed - `removedTime` string, date-time — The time this transfer was removed - `commentedTime` string, date-time — The time this transfer was commented on - `failedTime` string, date-time — The time this transfer failed - `regeneratedTime` string, date-time — The time this transfer was regenerated - `replacedTime` string, date-time — The time this transfer was replaced - `replacingTime` string, date-time — The time this transfer started replacing another - `abandonedTime` string, date-time — The time this transfer was abandoned - `signedDate` string, date-time — The date this transfer was signed (legacy field) - `customerApprovedTime` string, date-time — The time this transfer was approved by the customer (trust transfers) - `idVerificationTime` string, date-time — The time identity verification was completed (trust transfers) - `trustSignedTime` string, date-time — The time this transfer was signed by trust (trust transfers) - `trustFinalApprovalTime` string, date-time — The time this transfer received final trust approval (trust transfers) - `walletLabel` string — Label of the wallet associated with this transfer - `enterpriseName` string — Name of the enterprise associated with this transfer - `elliptic` string — Elliptic risk score information (trust transfers) - `senderInformationVerified` boolean — Whether sender information has been verified (trust transfers) - `buildParams` object — Parameters used to build the transaction - `entries` object[] — An array of objects describing the change in address balances made as a result of this Transfer - `address` string — An address affected by this Transfer - `wallet` string - `value` integer — The change (in base units) in the address's balance - `valueString` string - `isChange` boolean — True if this address is a change address (only exists for UTXO coins) and if this is a `sent` Transfer - `isPayGo` boolean — True if this address is the BitGo PayGo wallet - `token` string — If this is a token entry, the token's symbol - `label` string — If this address was labeled by the user, this is the label - `failed` boolean — true if this entry is failed. - `associatedNativeCoinAddress` string — The native coin receive address associated with the solana ATA address. This is currently present only for BitGo addresses. - `memo` string — Memo associated with this entry. Only available for STX, EOS, SOL, NEAR, and POLYX. For other coins (XLM, XRP, Cosmos-based, TON, Tempo), memo is stored at the transaction level or appended to the address. - `type` string — The type of this entry (e.g., transfer, fee, contract_call). - `nftId` string — NFT ID associated with this entry. Only present for NFT transfers. - `nftSymbol` string — NFT symbol associated with this entry. Only present for NFT transfers. - `usersNotified` boolean — Whether BitGo already sent notifications to the users of the transfer wallet - `label` string — Address labels (if any) from entries concatenated. - `replaces` string[] — Transaction IDs that this transfer replaces. - `replacedBy` string[] — Transaction IDs that replace this transfer. - `riskIndicators` string[] — Risk indicators detected on this transfer (e.g. SELFDESTRUCT opcode). Transfers with risk indicators will not trigger webhook or email notifications. - `inputs` Unspent[] — If this is a Transfer on a UTXO coin, the array of inputs - `id` string — The id of the unspent in the form : - `address` string — The address of this unspent - `value` integer - `valueString` string - `blockHeight` integer — The block this Unspent was created in - `date` string, date-time — The date this unspent was created - `coinbase` boolean — True if this unspent came from the coinbase transaction - `wallet` string - `fromWallet` string - `chain` integer — The type of this unspent's address (P2SH, P2WSH, etc...) - `index` integer — A monotonic counter used when creating new addresses - `redeemScript` string — The Script program used to cryptographically verify spending this unspent - `witnessScript` string — The segwit Script program used to cryptographically verify spending this unspent - `isSegwit` boolean - `outputs` Unspent[] — If this is a Transfer on a UTXO coin, the array of outputs - `id` string — The id of the unspent in the form : - `address` string — The address of this unspent - `value` integer - `valueString` string - `blockHeight` integer — The block this Unspent was created in - `date` string, date-time — The date this unspent was created - `coinbase` boolean — True if this unspent came from the coinbase transaction - `wallet` string - `fromWallet` string - `chain` integer — The type of this unspent's address (P2SH, P2WSH, etc...) - `index` integer — A monotonic counter used when creating new addresses - `redeemScript` string — The Script program used to cryptographically verify spending this unspent - `witnessScript` string — The segwit Script program used to cryptographically verify spending this unspent - `isSegwit` boolean ## Other responses - `206` — Partial Content - `400` — Bad Request --- [API](https://skmtc.net/bitgo/apis/bitgo-api.md) · [All operations](https://skmtc.net/bitgo/apis/bitgo-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/bitgo/bitgo-api/revisions/e445c15e5bee/schema)