> ## Documentation Index > Fetch the complete documentation index at: https://docs.meshconnect.com/llms.txt > Use this file to discover all available pages before exploring further. # Report a native (non-bridged) deposit your platform has already detected on one of its own deposit addresses. > For deposits that do not need bridging — the end user sent an asset you accept natively to the deposit address your platform shows them — there is no `POST /api/v1/bridging/address` call and Mesh is not in the payment path. Call this endpoint once you have seen the transaction on chain so Mesh records it, verifies it independently and sends the same transfer webhooks a bridged deposit produces, giving you one record and one reconciliation stream for every deposit. **What happens:** Mesh creates the transfer as `pending` with the reported hash, then verifies on chain that the transaction is confirmed and credited `destination.address` in `destination.asset`. On verification the transfer moves to `succeeded` and the `succeeded` webhook fires (with the transaction hash and the on-chain amount). A transaction that conclusively did not deliver (it reverted, or moved none of the asset to the address), or one whose credit cannot be verified by `expirationTime`, marks the transfer `failed` and a `failed` webhook is sent. No `pending` webhook is sent. This endpoint does not return transfer status; use webhooks or the transfers API with `tracking.transferId`. **One call per on-chain transaction.** The transaction hash is the deposit's identity: a player who deposits several times to the same saved address produces several transactions, and each needs its own call with its own `transactionId`. Call it after detection, not when the address is displayed. **Idempotency:** a `transactionId` is single-use per `userId`. Re-submitting the same `transactionId` + `userId` with the same destination and `transactionHash` returns the original record (same `transferId`) in any state, so retries are safe. Re-submitting it with a different destination or hash, or with a `transactionId` already used for a bridged address, is a `400` (and a `transactionId` used here cannot later mint a bridged address). Reporting a `transactionHash` already tracked for the same destination under another `transactionId` is a `409` (`transferAlreadyRequested`) naming the existing transfer; the same hash crediting a different address of yours (one transaction paying several users) is a separate deposit and is accepted. **Networks and assets:** `destination.network` is a CAIP-2 id of an EVM, Solana, Tron, Bitcoin or XRP Ledger network and `destination.asset` a token symbol Mesh knows on that network; any other network type is a `400`, and an asset Mesh cannot verify on that network is a `400` (`symbolNotSupported`). `destination.address` must be a well-formed address for that network (`invalidDestinationAddress` otherwise) and `transactionHash` a well-formed transaction id for it (EVM, Tron, Bitcoin, XRP Ledger: 32 bytes hex, `0x` optional; Solana: base58 signature). `amount` is informational: the on-chain credit is authoritative and is what the `succeeded` webhook carries, so a differing `amount` is logged but does not fail the deposit. ## OpenAPI ````yaml post /api/v1/bridging/notify openapi: 3.0.1 info: title: Mesh Connect Integration API description: >- Mesh allows users to connect accounts of financial institutions, crypto exchanges, and self-custody wallets. Mesh handles credential validation, MFA, and error handling for each integration. After an account is connected, Mesh allows client applications to read holdings, transaction history and balances and execute crypto transfers (with user approval). version: '1.0' servers: - url: https://integration-api.meshconnect.com - url: https://sandbox-integration-api.meshconnect.com security: - Client-Secret: [] Client-Id: [] tags: - name: BlockchainQuery - name: CatalogGasSponsorship - name: CatalogSubscription - name: TokenNetworkPairs - name: RampKyc - name: RampPayment - name: RampSession - name: Integrations account information - name: Managed Account Authentication description: >- The recommended approach for account authentication. Front manages multiple authentication flows and handles all authentication steps such as MFA codes and OAuth redirect through our web and mobile SDKs. - name: Portfolio description: | ### Supported integrations: ```Robinhood``` ```Coinbase``` ```Kraken``` ```CryptoCom``` ```OpenSea``` ```Binance``` ```Gemini``` ```OkCoin``` ```KuCoin``` ```CexIo``` ```BinanceInternational``` ```Bitstamp``` ```GateIo``` ```Okx``` ```BitFlyer``` ```Coinlist``` ```Huobi``` ```Bitfinex``` ```KrakenDirect``` ```BinanceInternationalDirect``` ```BitfinexDirect``` ```Bybit``` ```Paxos``` ```CoinbasePrime``` ```BtcTurkDirect``` ```KuCoinDirect``` ```OkxOAuth``` ```ParibuDirect``` ```RobinhoodConnect``` ```BlockchainCom``` ```BitsoDirect``` ```BinanceOAuth``` ```BybitDirect``` ```ParibuOAuth``` ```BinanceTrDirect``` ```BybitDirectMobile``` ```Sandbox``` ```Uphold``` ```SandboxCoinbase``` ```KrakenOAuth``` ```BluvoKrakenOAuth``` ```SandboxKrakenOAuth``` ```DeFiWallet``` - name: Balance description: | ### Supported integrations: ```Robinhood``` ```Coinbase``` ```Kraken``` ```CryptoCom``` ```Binance``` ```Gemini``` ```OkCoin``` ```KuCoin``` ```CexIo``` ```BinanceInternational``` ```Bitstamp``` ```GateIo``` ```Okx``` ```BitFlyer``` ```Coinlist``` ```Huobi``` ```Bitfinex``` ```KrakenDirect``` ```BinanceInternationalDirect``` ```BitfinexDirect``` ```Bybit``` ```Paxos``` ```CoinbasePrime``` ```BtcTurkDirect``` ```KuCoinDirect``` ```OkxOAuth``` ```ParibuDirect``` ```RobinhoodConnect``` ```BlockchainCom``` ```BitsoDirect``` ```BybitDirect``` ```ParibuOAuth``` ```BinanceTrDirect``` ```BybitDirectMobile``` ```Sandbox``` ```Uphold``` ```SandboxCoinbase``` ```KrakenOAuth``` ```BluvoKrakenOAuth``` ```SandboxKrakenOAuth``` - name: Transfers description: > ### Supported integrations: ```Robinhood``` ```Coinbase``` ```Kraken``` ```CryptoCom``` ```Binance``` ```Gemini``` ```OkCoin``` ```KuCoin``` ```BinanceInternational``` ```Bitstamp``` ```GateIo``` ```Okx``` ```Huobi``` ```Bitfinex``` ```KrakenDirect``` ```BinanceInternationalDirect``` ```BitfinexDirect``` ```Bybit``` ```Paxos``` ```CoinbasePrime``` ```BtcTurkDirect``` ```ParibuDirect``` ```RobinhoodConnect``` ```BlockchainCom``` ```BinanceConnect``` ```RevolutConnect``` ```BinancePay``` ```BybitDirect``` ```ParibuOAuth``` ```PayPalConnect``` ```CoinbaseRamp``` ```BybitDirectMobile``` ```Sandbox``` ```CryptoComPay``` ```Uphold``` ```BinancePayOnchain``` ```SandboxCoinbase``` ```BybitPay``` ```CashApp``` ```SandboxKrakenOAuth``` ```KrakPay``` ```OkxPay``` ```BybitPayPsp``` ```DeFiWallet``` ### Integration-specific notes: #### Robinhood: Cryptocurrency transfers should be enabled in Robinhood settings. Transfers are disabled by default, enabling them for end users requires a review from Robinhood. Please note: * `MfaCode` parameter is required to initiate a transaction in Robinhood. * The user's security settings should be configured to use an authenticator application. * Robinhood doesn't allow initiation of transactions if the authenticator application is not configured. #### Coinbase: `MfaCode` parameter should be used to initiate transactions in Coinbase. * If the end user's Coinbase account is configured to use text messages (SMS) for two factor authentication, the API will return `MfaRequired` status, and a text code will then be sent by Coinbase. The code is expected to be provided in the subsequent call using the `MfaCode` request field * If the account is configured to use an authenticator application, the API is expecting to get the code in the `MfaCode` request field. #### Kraken: Kraken requires the explicit chain name to be provided (e.g. `Dogecoin` or `Ethereum (ERC20)`). The list of possible chains can be obtained by calling `symbol/details` endpoint. To initiate a transaction, a Kraken Address Key name should be provided in `TargetAddress` field. Target address should be added using Kraken UI, then its name should be used. #### Binance: `Enable Withdrawals` permission should be given to the user's API key to initiate transfers with Binance Us. Binance requires adding the IP address to the list of trusted IPs to be able to create API keys with transfer permission. * Please reach out to Front to get the static IP address. This address should be provided to the end user, and the user should be instructed to add it to the list of trusted IP addresses. * By default, the permission to enable withdrawals is turned off. If the end user's API key does not have the permission, asset transfers will not be available. #### KuCoin: KuCoin requires adding the IP address to the list of trusted IPs to be able to create API keys with transfer permission. `Fee` parameter should be used to initiate a transaction in KuCoin. Please note: * Please reach out to Front to get the static IP address. This address should be provided to the end user, and the user should be instructed to add it to the list of trusted IP addresses. * All currencies have their minimum `fee` and `amount` requirements. Please use `symbol/details` endpoint to get this data for a particular symbol. * KuCoin requires chain name to be provided for getting deposit address or initiating a cryptocurrency transfer. Some cryptocurrencies are supported over multiple chains. It's recommended to use `symbol/details` endpoint to get the list of supported chains and show it to the end user to select a target one. #### BinanceInternational: `Enable Withdrawals` permission should be given to the user's API key to initiate transfers with Binance International. Binance requires adding the IP address to the list of trusted IPs to be able to create API keys with transfer permission. * Please reach out to Front to get the static IP address. This address should be provided to the end user, and the user should be instructed to add it to the list of trusted IP addresses. * By default, the permission to enable withdrawals is turned off. If the end user's API key does not have the permission, asset transfers will not be available. #### GateIo: Gate.io requires adding IP address to the list of trusted IP addresses to be able to initiate a cryptocurrency transfers. Withdrawal address should be already verified or added on the Gate.io UI (in mobile application or on the web site). * Please reach out to Front to get the static IP address for withdrawals. This address should be provided to the end user, and the user should be instructed to add it to the list of trusted IP addresses. * Only verified withdrawal blockchain addresses are allowed for withdrawal with Gate.io API. * Gate.io requires chain name to be provided for getting deposit address or initiating a cryptocurrency transfer. Some cryptocurrencies are supported over multiple chains. It's recommended to use `symbol/details` endpoint to get the list of supported chains and show it to the end user to select a target one. #### Huobi: Warning: Huobi does not refund executed deposits that are below the `Minimum Deposit Amount` * Please check the MinimumDepositAmount in Get Deposit Address response in order to avoid making a deposit below the minimum amount * Huobi does not allow withdrawals to addresses that are not white-listed, please add the address that you would like to withdraw to the white list of addresses through the UI so that a withrawal can be processed #### Bitfinex: * The hash of transfer is not available when making a transfer in Bitfinex. To get the hash please re-query the transfer using the transaction id. * Bitfinex does not separate sub-accounts when returning the list of transfers.Therefore the same list of transfers is returned for all Bitfinex sub-accounts. #### KrakenDirect: Kraken requires the explicit chain name to be provided (e.g. `Dogecoin` or `Ethereum (ERC20)`). The list of possible chains can be obtained by calling `symbol/details` endpoint. To initiate a transaction, a Kraken Address Key name should be provided in `TargetAddress` field. Target address should be added using Kraken UI, then its name should be used. #### BitfinexDirect: * The hash of transfer is not available when making a transfer in Bitfinex. To get the hash please re-query the transfer using the transaction id. * Bitfinex does not separate sub-accounts when returning the list of transfers.Therefore the same list of transfers is returned for all Bitfinex sub-accounts. - name: Assets - name: Managed Transfers - name: Wallets - name: Headless Bridging description: >- Mesh's cross-chain bridging engine as a pure API, with no Mesh-hosted UI or SDK. Discover bridged routes, quote a pay-in amount and generate a single-use deposit address that bridges funds to the destination the user selected. Enabled per client; see https://docs.meshconnect.com/resources/headless-bridging. paths: /api/v1/bridging/notify: post: tags: - Headless Bridging summary: >- Report a native (non-bridged) deposit your platform has already detected on one of its own deposit addresses. description: "For deposits that do not need bridging — the end user sent an asset you accept natively to the deposit\r\naddress your platform shows them — there is no `POST /api/v1/bridging/address` call and Mesh is not\r\nin the payment path. Call this endpoint once you have seen the transaction on chain so Mesh records it,\r\nverifies it independently and sends the same transfer webhooks a bridged deposit produces, giving you one\r\nrecord and one reconciliation stream for every deposit.\r\n \r\n**What happens:** Mesh creates the transfer as `pending` with the reported hash, then verifies on\r\nchain that the transaction is confirmed and credited `destination.address` in `destination.asset`.\r\nOn verification the transfer moves to `succeeded` and the `succeeded` webhook fires (with the\r\ntransaction hash and the on-chain amount). A transaction that conclusively did not deliver (it reverted, or\r\nmoved none of the asset to the address), or one whose credit cannot be verified by `expirationTime`,\r\nmarks the transfer `failed` and a `failed` webhook is sent. No `pending` webhook is sent. This endpoint does not return transfer status; use webhooks or the\r\ntransfers API with `tracking.transferId`.\r\n \r\n**One call per on-chain transaction.** The transaction hash is the deposit's identity: a player who\r\ndeposits several times to the same saved address produces several transactions, and each needs its own\r\ncall with its own `transactionId`. Call it after detection, not when the address is displayed.\r\n \r\n**Idempotency:** a `transactionId` is single-use per `userId`. Re-submitting the same\r\n`transactionId` + `userId` with the same destination and `transactionHash` returns the\r\noriginal record (same `transferId`) in any state, so retries are safe. Re-submitting it with a\r\ndifferent destination or hash, or with a `transactionId` already used for a bridged address, is a\r\n`400` (and a `transactionId` used here cannot later mint a bridged address). Reporting a\r\n`transactionHash` already tracked for the same destination under another `transactionId` is a\r\n`409` (`transferAlreadyRequested`) naming the existing transfer; the same hash crediting a\r\ndifferent address of yours (one transaction paying several users) is a separate deposit and is accepted.\r\n \r\n**Networks and assets:** `destination.network` is a CAIP-2 id of an EVM, Solana, Tron, Bitcoin or XRP Ledger\r\nnetwork and `destination.asset` a token symbol Mesh knows on that network; any other network type is a\r\n`400`, and an asset Mesh cannot verify on that network is a `400` (`symbolNotSupported`).\r\n`destination.address` must be a well-formed address for that network\r\n(`invalidDestinationAddress` otherwise) and `transactionHash` a well-formed transaction id for it\r\n(EVM, Tron, Bitcoin, XRP Ledger: 32 bytes hex, `0x` optional; Solana: base58 signature). `amount` is informational: the\r\non-chain credit is authoritative and is what the `succeeded` webhook carries, so a differing\r\n`amount` is logged but does not fail the deposit." requestBody: content: application/json: schema: allOf: - $ref: '#/components/schemas/NotifyNativeDepositRequest' description: "Request body for `POST /api/v1/bridging/notify`.\r\n\n\r\nReports a native (non-bridged) deposit the client has already detected on one of its own deposit addresses,\r\nso Mesh records it, verifies it on chain and emits the same transfer webhooks a bridged deposit produces.\r\nOne call per on-chain transaction.\r\n\n\r\nIdempotent per `transactionId` scoped to `userId` and B2B client/environment: a retry with the same\r\ndestination and `transactionHash` returns the original record. The same `transactionId` with a\r\ndifferent destination or hash is a `400`; a `transactionHash` already tracked for the same destination\r\nunder another `transactionId` is a `409` (`transferAlreadyRequested`). The same hash crediting a\r\ndifferent address is a separate deposit.\r\n" responses: '200': description: >- Deposit recorded (or the original record returned on an idempotent retry); verification is in progress. content: application/json: schema: $ref: '#/components/schemas/NotifyNativeDepositResponseApiResult' '400': description: >- Request is missing required fields, the network is unknown or not an EVM / Solana / Tron / Bitcoin / XRP Ledger network, the asset is not supported on that network (`symbolNotSupported`), the address is not valid for the network (`invalidDestinationAddress`), the hash or amount is malformed, or the `transactionId` was already used with a different destination or hash. content: application/json: schema: $ref: '#/components/schemas/ApiResult' example: status: ok message: '' errorHash: 014bffeb teamCode: Q9 errorType: '' '401': description: Unauthorized — Client ID or Client Secret are missing or incorrect. content: application/json: schema: {} '403': description: >- Headless bridging is not enabled for this client (`permissionDenied`), or the API key does not have the write scope required for this endpoint. content: application/json: schema: $ref: '#/components/schemas/ApiResult' example: status: ok message: '' errorHash: 014bffeb teamCode: Q9 errorType: '' '409': description: >- The `transactionHash` is already tracked for this destination by another transfer (`transferAlreadyRequested`). The message names the existing transfer and its `transactionId`. content: application/json: schema: $ref: '#/components/schemas/ApiResult' example: status: ok message: '' errorHash: 014bffeb teamCode: Q9 errorType: '' components: schemas: NotifyNativeDepositRequest: required: - destination - transactionHash - transactionId - userId type: object properties: userId: maxLength: 384 minLength: 1 type: string description: "Your platform's unique identifier for the end user who made this deposit.\r\nCombined with `transactionId` to enforce idempotency." transactionId: maxLength: 128 minLength: 1 type: string description: "Your platform's unique identifier for this deposit. One per on-chain transaction; re-submitting the same\r\nvalue with the same destination and hash returns the previously created record." destination: allOf: - $ref: '#/components/schemas/BridgingDestinationWithAddressSpec' description: "Where the deposit landed: the network (CAIP-2 id), the asset symbol, and your platform's deposit address\r\nthat received the funds. Mesh verifies the reported transaction against this destination." transactionHash: maxLength: 128 minLength: 1 type: string description: >- Hash of the on-chain transaction that delivered the deposit to `destination.address`. amount: maxLength: 64 type: string description: "Optional amount received, as a decimal string in `destination.asset` units (e.g. `\"125.5\"`).\r\nInformational: the on-chain credit is authoritative and is what the `succeeded` webhook carries; a\r\ndiffering value is logged for reconciliation but does not fail the deposit." nullable: true additionalProperties: false description: "Request body for `POST /api/v1/bridging/notify`.\r\n\n\r\nReports a native (non-bridged) deposit the client has already detected on one of its own deposit addresses,\r\nso Mesh records it, verifies it on chain and emits the same transfer webhooks a bridged deposit produces.\r\nOne call per on-chain transaction.\r\n\n\r\nIdempotent per `transactionId` scoped to `userId` and B2B client/environment: a retry with the same\r\ndestination and `transactionHash` returns the original record. The same `transactionId` with a\r\ndifferent destination or hash is a `400`; a `transactionHash` already tracked for the same destination\r\nunder another `transactionId` is a `409` (`transferAlreadyRequested`). The same hash crediting a\r\ndifferent address is a separate deposit.\r\n" NotifyNativeDepositResponseApiResult: type: object properties: status: enum: - ok - serverFailure - permissionDenied - badRequest - notFound - conflict - tooManyRequest - locked - unavailableForLegalReasons - serviceUnavailable allOf: - $ref: '#/components/schemas/ApiResultStatus' readOnly: true message: type: string description: A message generated by the API nullable: true displayMessage: type: string description: User-friendly display message that can be presented to the end user nullable: true errorHash: type: string description: >- An error grouping hash from string components and caller information. Used by bugsnag on FE for correct error grouping nullable: true readOnly: true teamCode: type: string description: "Opaque team code for error routing. Resolved from exception origin or caller file path via CODEOWNERS.\r\nFormat: 2-character code (e.g., \"7K\", \"M2\"). Use for alerting/routing, not display." nullable: true readOnly: true errorType: type: string description: "Strictly-typed error type that is explaining the reason of an unsuccessful status of the operation.\r\nAll possible error types are available in the documentation." nullable: true errorData: nullable: true readOnly: true content: allOf: - $ref: '#/components/schemas/NotifyNativeDepositResponse' description: "Response body for `POST /api/v1/bridging/notify`.\r\n\n\r\nEchoes the recorded deposit and the tracking IDs to correlate the `succeeded` / `failed` webhook\r\nMesh sends once the reported transaction has been verified on chain (or could not be by\r\n`expirationTime`). This endpoint does not return transfer status.\r\n" nullable: true additionalProperties: false ApiResult: type: object properties: status: enum: - ok - serverFailure - permissionDenied - badRequest - notFound - conflict - tooManyRequest - locked - unavailableForLegalReasons - serviceUnavailable allOf: - $ref: '#/components/schemas/ApiResultStatus' readOnly: true message: type: string description: A message generated by the API nullable: true displayMessage: type: string description: User-friendly display message that can be presented to the end user nullable: true errorHash: type: string description: >- An error grouping hash from string components and caller information. Used by bugsnag on FE for correct error grouping nullable: true readOnly: true teamCode: type: string description: "Opaque team code for error routing. Resolved from exception origin or caller file path via CODEOWNERS.\r\nFormat: 2-character code (e.g., \"7K\", \"M2\"). Use for alerting/routing, not display." nullable: true readOnly: true errorType: type: string description: "Strictly-typed error type that is explaining the reason of an unsuccessful status of the operation.\r\nAll possible error types are available in the documentation." nullable: true errorData: nullable: true readOnly: true additionalProperties: false BridgingDestinationWithAddressSpec: required: - address - asset - network type: object properties: network: minLength: 1 type: string description: "CAIP-2 network identifier for the token's network.\r\n\nExamples: `eip155:1` (Ethereum Mainnet), `eip155:137` (Polygon),\r\n`eip155:8453` (Base), `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp` (Solana Mainnet)." asset: minLength: 1 type: string description: Token symbol, case-insensitive (e.g. `USDC`, `ETH`, `MATIC`). address: maxLength: 200 minLength: 1 type: string description: "On-chain wallet address on the destination network that will receive the bridged funds.\r\nMust be a valid address for the specified `network`." additionalProperties: false description: "A bridging destination (network and asset) together with the on-chain wallet address where\r\nbridged funds should be delivered." ApiResultStatus: enum: - ok - serverFailure - permissionDenied - badRequest - notFound - conflict - tooManyRequest - locked - unavailableForLegalReasons - serviceUnavailable type: string NotifyNativeDepositResponse: required: - destination - expirationTime - tracking - transactionHash - warnings type: object properties: tracking: allOf: - $ref: '#/components/schemas/BridgingTracking' description: "Internal IDs for tracking this deposit. Store these to correlate webhook events and status updates\r\nback to this specific transfer." nullable: true destination: allOf: - $ref: '#/components/schemas/BridgingDestinationWithAddressSpec' description: >- The destination (network, asset, address) the deposit was recorded against, normalized by Mesh. nullable: true transactionHash: type: string description: The on-chain transaction hash Mesh is verifying, normalized. nullable: true amount: type: string description: >- The reported amount in `destination.asset` units, when one was supplied. nullable: true expirationTime: type: integer description: "Unix timestamp (seconds) by which Mesh must verify the transaction. If it cannot, the transfer is marked\r\n`failed` and a `failed` webhook is sent." format: int64 warnings: type: array items: type: string description: >- Operational notes about verification, idempotency and the failure deadline. nullable: true additionalProperties: false description: "Response body for `POST /api/v1/bridging/notify`.\r\n\n\r\nEchoes the recorded deposit and the tracking IDs to correlate the `succeeded` / `failed` webhook\r\nMesh sends once the reported transaction has been verified on chain (or could not be by\r\n`expirationTime`). This endpoint does not return transfer status.\r\n" BridgingTracking: required: - transactionId - transferId - userId type: object properties: userId: type: string description: "The end-user identifier supplied in the originating request.\r\nEchoed back for client-side reconciliation." nullable: true transactionId: type: string description: "The transfer identifier supplied in the originating request.\r\nEchoed back for client-side reconciliation." nullable: true transferId: type: string description: "Mesh-internal unique identifier for this transfer record.\r\nUse this ID when querying transfer status or matching incoming webhook payloads." format: uuid additionalProperties: false description: "Identifiers for tracking a headless bridge transfer through the Mesh platform.\r\nStore these values to correlate webhook events and status polling with the transfer\r\ninitiated by `POST /api/v1/bridging/address` or reported by `POST /api/v1/bridging/notify`." securitySchemes: Client-Secret: type: apiKey description: Contact Mesh to get client Secret name: X-Client-Secret in: header Client-Id: type: apiKey description: Contact Mesh to get client Id name: X-Client-Id in: header ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.