Skip to main content
Mesh has a small set of core concepts that come up throughout the guides. This page defines each one so you can build with a clear mental model. Link is Mesh’s hosted UX that facilitates the user journey of connecting accounts, initiating transfers, and verifying wallets. When a user “uses Mesh”, they’re in Link. Link is available on five client-side SDKs: web, iOS, Android, React Native, Flutter. You initialize it with a Link Token and wire up callback functions to respond to what the user does. Link handles the complex parts: OAuth flows, wallet connections, transfer previews, compliance steps, and success/error states. All you need to provide is an entry point (eg. a button) and a response to the result. A Link Token is how you start every user session. You request one from Mesh’s API on your server, passing parameters that configure the experience — what transfer type the user will see, where the funds should go, any amount constraints, display currency, and so on. The token is short-lived (10 minutes) and single-use. Your server requests it, passes it to the client, and the client uses it to initialize a Link session. Everything you want to configure about a user session goes into the Link Token request. See Fetch a Link Token for use-case-specific examples.

​
Integrations

Integrations are the exchanges (Coinbase, Binance, etc.) and wallets (MetaMask, Phantom, etc.) that Mesh connects to. When users connect their account inside Link, they’re authenticating with one of these integrations. Mesh handles the authentication flows, OAuth connections, and API calls to these integrations on your behalf. You don’t need to build any direct integrations yourself.

​
Mesh Managed Tokens (MMT)

When a user connects an exchange account in Link, Mesh can persist that authorization for future sessions. Mesh Managed Tokens (MMT) is the system that stores and refreshes those tokens on your behalf. The key concept: you store a tokenId (a stable identifier Mesh gives you) and pass it back to the SDK on subsequent sessions. If the token is still valid, the user skips re-authentication entirely and can complete a transfer in one or two taps. Mesh handles all token refresh logic. Even if an underlying access token expires, the tokenId you store never changes — no backend updates required on your part. See Supercharge return-users for implementation details.

​
SmartFunding

SmartFunding is Mesh’s intelligent transfer-routing capability. When a user has balances of multiple assets, SmartFunding automatically identifies the best source to fulfill a transfer — factoring in available balance, network compatibility, fees, and speed. Clients with SmartFunding capabilities can offer users a more streamlined experience, where Mesh handles the “which account do I send from?” decision intelligently in the background.

​
refundAddress

Mesh returns the refundAddress field in both the managed transfers endpoint (/api/v1/transfers/managed/mesh) as well as the transfer status webhook payload (see Transfer status webhooks guide for more info). This field can be used for reverse money movement in payment flows, or withdrawals in deposit flows. This address can be used to send the specified asset on the specified network back to the user. For wallet transfers, this is the same as where the original incoming transfer originates from. But for exchange transfers, it is a user-specific deposit address within their exchange account (exchanges send onchain from omnibus hot wallets, so the originating address for the original incoming transfer cannot be used for refunds).

​
Sub-clients

Sub-clients are child accounts under your main Mesh account. They’re used in B2B or PSP (payment service provider) contexts where you’re managing integrations on behalf of multiple downstream merchants or business customers. Each sub-client gets its own API credentials, branding configuration, compliance settings, and data isolation. You can create and manage sub-clients programmatically via the Mesh API. If you’re building a single product for your own users, you don’t need sub-clients. See Managing sub-clients for more details.

​
Sandbox

Mesh’s sandbox environment is a full replica of production for testing purposes, using a separate base URL: https://sandbox-integration-api.meshconnect.com In sandbox, you use pre-configured test accounts to simulate real exchange connections and transfers. No real assets move. Sandbox API keys are separate from production keys and are managed in the same dashboard section. See Sandbox & Testnets for test credentials and wallet testing instructions.

​
Webhooks

Webhooks are server-to-server event notifications Mesh sends to a URL you register. The most important event is transfer.succeeded — which confirms that a transfer has actually been posted to the blockchain or exchange, as opposed to just being initiated. Because exchanges can take anywhere from seconds to days to post a transaction, webhooks are how you reliably know when to credit a user’s account or release inventory. You should always consume webhooks rather than relying solely on the onTransferFinished SDK callback for transfer confirmation. Register your webhook callback URL in the Mesh dashboard under Account > API keys > Webhooks.

​
Transfer types

Mesh supports several transfer types, each configuring a different user journey inside Link:
  • Deposit — the user sends crypto from their exchange or wallet to your platform’s address. The most common use case.
  • Payment — the user sends a specific crypto amount to your payment wallet. Similar to deposit, but with a fixed amount per destination address.
  • Onramp — the user purchases crypto with fiat (via Binance Connect or other onramp providers) and sends it to your address.
  • Withdrawal — the user connects their account so you can retrieve their deposit addresses for use with Mesh’s managed transfer API.
  • Verify — the user signs a message with their self-custody wallet to prove ownership of a specific address.
The transfer type is set in the Link Token request via the transferType parameter. Transfer types can be combined — for example, you can require wallet verification as part of a deposit or payment flow.
AI coding reference — a compact summary of this page’s APIs, parameters, and patterns for use by AI coding assistants (following the llms.txt standard). Human readers can safely ignore this.llms.txt — ConceptsGlossary of core Mesh terms used across all guides.Link: Mesh’s hosted UX (iframe / native view) for connecting accounts, initiating transfers, verifying wallets. Available on 5 SDKs: Web, iOS, Android, React Native, Flutter.Link Token: Short-lived (10 min), single-use token requested server-side via POST /api/v1/linktoken. Configures the entire user session. Every session starts with one.Integrations: Exchanges (Coinbase, Binance, etc.) and wallets (MetaMask, Phantom, etc.) that Mesh connects to. Mesh handles all auth flows.Mesh Managed Tokens (MMT): Mesh stores and refreshes OAuth tokens on your behalf. You store a stable tokenId. User skips re-auth on return visits. tokenId never changes even if underlying access token rotates.SmartFunding: Auto-selects best source asset for a transfer based on available balance, network compatibility, fees, and speed.refundAddress: Address funds can be returned to. For exchange transfers, this is a user deposit address within the exchange (not the originating on-chain address, which is an omnibus hot wallet). Returned in webhooks and GET /api/v1/transfers/managed/mesh.Sub-clients: Child Mesh accounts for B2B/PSP use cases. Each gets independent branding, API credentials, and compliance settings.Webhooks: Server-to-server event notifications from Mesh. Use EventId as idempotency key (stable across retries; Id changes per delivery). At-least-once delivery. Register at Dashboard > Account > API keys > Webhooks.Transfer types: deposit | payment | onramp — set via transferType in Link Token request | withdrawal — no transferType needed (user just connects account; no transferOptions required) | verify — uses verifyWalletOptions, not transferType. Types can be combined (e.g. verify + deposit).