> ## 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. # How it all fits together By the end of this page, you'll have a clear mental model of how the Mesh components — Link Token, SDK, callbacks, and webhooks — connect in a complete integration. Ready to build? Jump straight to the [15-minute quickstart](/build/15min-quickstart) or start from [Prepare to build](/build/prepare-to-build). Come back here if you want a map of how the pieces fit. ## The big picture Every Mesh integration involves three parties: your **server**, your **client app**, and **Mesh**. Here's the full flow from button click to confirmed transfer. Image ## Step by step ### Step 1: Request a Link Token (server-side) Every Mesh session starts on your server. When a user triggers a Mesh interaction — clicking a "Deposit" or "Pay" button — your server makes a `POST /api/v1/linktoken` request to Mesh. This request configures the entire user session: transfer type (deposit, payment, onramp), destination address, amount constraints, supported networks and assets, display currency, and more. The Link Token encodes all of this configuration without exposing it to the client. Link Tokens are short-lived (10 minutes) and single-use. Request a new one for each user session. → [Fetch a Link Token](/build/fetch-link-token) for use-case-specific examples and the full parameter reference. ### Step 2: Initialize and launch the SDK (client-side) Your client receives the Link Token (passed through your own API), initializes the Mesh SDK with it, and launches Link. From this point, Mesh handles everything the user sees: the integration catalog, authentication flows, transfer preview, compliance steps, and success/error states. Link is available for five platforms — Web, iOS, Android, React Native, Flutter — each with a platform-specific initialization pattern. → [Launch the Mesh SDK](/build/launch-sdk) for all five platforms, including overlay, embedded, and Paylinks options. ### Step 3: Handle SDK callbacks (client-side) When the user takes a significant action inside Link, the SDK fires callback functions in your app. The four callbacks: * **`onIntegrationConnected`** — fires when the user successfully connects their exchange or wallet. The payload includes an `accessToken` (with a `tokenId`) that you should store server-side to enable one-tap return-user flows. * **`onTransferFinished`** — fires when a transfer has been submitted. Contains `status`, `transferId`, `txHash`, and transfer details. Use this to update your UI and trigger any immediate client-side logic. * **`onExit`** — fires whenever Link closes, regardless of outcome. Check the `page` field to detect whether the user finished the flow. * **`onEvent`** — fires for granular user interactions throughout Link. Useful for analytics and specific UX logic.
`onTransferFinished` fires when a transfer request is acknowledged by the provider — not when it's confirmed onchain. For final on-chain or exchange confirmation, always use webhooks (Step 4). A transfer that fires `onTransferFinished` with `status: pending` may still fail.
→ [Use Mesh's callback functions](/build/callbacks) for platform-specific setup and full payload details. → [Mesh SDK events](/resources/sdk-events) for the complete event reference. ### Step 4: Verify the outcome with webhooks (server-side) `onTransferFinished` tells you a user's transfer request was acknowledged by the provider. Webhooks tell you what actually happened onchain. After a transfer is submitted, Mesh sends POST requests to your registered webhook URL as the transfer status changes: first `pending`, then either `succeeded` or `failed`. Use the `succeeded` event — not the SDK callback — to credit a user's account, release inventory, or trigger downstream business logic. **Webhooks are server-to-server.** They arrive at your registered URL independently of whether the user's browser or app is still open. Always rely on the `succeeded` webhook for final transfer confirmation. Mesh signs each webhook with HMAC-SHA256 — always verify the signature before processing the payload. Webhooks may be retried and delivered more than once; use `EventId` as your idempotency key. → [Transfer status webhooks](/resources/webhooks) for full setup including HMAC verification and the complete payload reference. ## Return users: skipping re-authentication Once a user has connected their account, they can skip re-authentication on future visits using **Mesh Managed Tokens (MMT)**. When `onIntegrationConnected` fires, save the `tokenId` from the `accessToken` payload on your server. On the user's next visit, pass the `accessToken` object to the SDK. The user can then complete a transfer in one or two taps with no re-login. Mesh handles all token refresh logic. The `tokenId` you store never changes, even if the underlying access token expires. → [Supercharge return-users](/build/return-users) for implementation details across all five SDK platforms. ## What's next * [15-minute quickstart](/build/15min-quickstart) — build a working end-to-end integration in 5 steps * [Prepare to build](/build/prepare-to-build) — get your Mesh dashboard account, API keys, and SDK installed * [Concepts](/resources/concepts) — definitions for every core term used across the guides *** *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](https://llmstxt.org/)). Human readers can safely ignore this.* **llms.txt — How it all fits together** Architecture overview of a complete Mesh integration. 3-party model: your server ↔ Mesh API, your client ↔ Mesh SDK (Link), Mesh → your webhook endpoint. **4-step integration flow**: 1. **Server → Mesh**: `POST /api/v1/linktoken` → returns `linkToken`. Configures the full user session (transfer type, destination, amounts, display options, etc.). 2. **Client → SDK**: Pass `linkToken` to `createLink()` / `LinkConfiguration` / `MeshConfiguration`. Call `openLink()`. Mesh handles all UX from this point. 3. **SDK → Client callbacks**: `onIntegrationConnected` (save `tokenId` for MMT) | `onTransferFinished` (update UI) | `onExit` (check `page` field) | `onEvent` (analytics) 4. **Mesh → Server webhooks**: `pending` → `succeeded` or `failed`. Use `succeeded` to credit users / release inventory. Always verify HMAC-SHA256 signature. **Critical distinction**: `onTransferFinished` fires when the provider acknowledges the request, not on-chain confirmation. Always use the `transfer.succeeded` webhook for final confirmation. **Return users (MMT)**: Store `tokenId` from `onIntegrationConnected`. Pass as `accessTokens` on next session → user skips re-auth entirely. **Platforms**: Web, iOS, Android, React Native, Flutter — all use the same Link Token; initialization pattern differs per SDK.