Travel Rule

You report Travel Rule data to Bit2Me on the gateway. You do not use Embed POST /v1/b2m/transaction/report for this. That Embed path is a callback Bit2Me sends to your backend about widget transactions. See Partner REST overview.

Endpoint

POST /v2/blockchain-manager/travel-rule-order/{orderId}

{orderId} is the operation id returned when you confirm a Wallet proforma. It is not the proforma id, and it is not the blockchain-manager orderId from address book.

This call is the Wallet legacy path only:

1. POST /v1/wallet/transaction/proforma
2. Confirm that proforma id with POST /v1/wallet/transaction
3. POST /v2/blockchain-manager/travel-rule-order/{orderId} with the operation id from step 2, only when the operation status is pending_user_information

Do not call this endpoint after an address-book draft. On that path, walletType, walletOwnership, and exchangeName are already on the entry. See Address book withdrawals.

Do not use Travel Rule v1 (POST /v1/blockchain-manager/travel-rule-order/{orderId} is deprecated).

If the Wallet path asks for this payload and you do not send it, the operation stays in pending_user_information and is cancelled within a few hours (exact TTL is not published). A public EUR threshold is not published — follow the status, not a hardcoded amount.

Payload fields from OpenAPI

Always send walletType (unhosted or exchange) and walletOwnership (own or other). Add exchangeName when the type is exchange. Send person fields when the API requires them for that case.

Public FAQ (not a substitute for the API response): Travel Rule frequently asked questions.

Where it sits in the withdrawal

Travel Rule is not destination-wallet verification. Verify a new on-chain address once (address book confirm). On Wallet legacy, submit Travel Rule only when that operation returns pending_user_information.