> ## Documentation Index > Fetch the complete documentation index at: https://docs.glider.fi/llms.txt > Use this file to discover all available pages before exploring further. # B2B API Overview > How Glider's B2B API manages flows for integrator access, user authority, Glider-managed automation, and onchain custody. Glider's B2B API is designed around a simple separation of authority: * **Integrator API keys identify the tenant.** They let your backend create strategies, enroll users, read portfolios, and request user-authorized actions within the scopes granted to that key. * **Users remain the root authority for their wallets and portfolios.** Enrollment and withdrawal flows require user signatures. An API key alone does not replace a user's wallet signature. * **Glider manages automation within scoped permissions.** Glider operates portfolios through smart-account session keys or delegated agent authority so scheduled and manual rebalances can execute without asking the user to sign every routine rebalance. * **Assets live onchain.** Portfolio assets are held in user-specific smart accounts or chain-native managed-account structures, not in an omnibus offchain ledger controlled by an integrator API key. This page is a concise mental model for integrators. More detail can be found about the system itself in our [Security Architecture](https://docs.glider.fi/guides/security-architecture). If you have questions about a specific wallet provider, signing flow, custody policy, or production rollout, contact the Glider team directly. ## Mental Model Think of Glider's B2B API as an orchestration between three roles: | Layer | Controlled by | What it authorizes | | --------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------- | | Integrator tenant | Your backend API key | Access to Glider API resources allowed by your scopes | | User root authority | The end-user wallet, smart wallet, or passkey root where supported | Enrollment, ownership, and user-approved withdrawals | | Glider's automation systems | Glider-managed agents and scoped session keys | Rebalance execution inside the permissions the user authorized | The integrator API key is an access credential for Glider's API. It is not a custody credential for user assets. ## What Glider Manages Centrally Glider centrally operates the offchain systems needed to make portfolio automation reliable: * API-key authentication, tenant identity, and scope enforcement. * Strategy and portfolio metadata. * Scheduling, orchestration, indexing, and operation status. * Market data, balance reads, policy checks, and route construction. * Managed automation agents backed by Glider key-management infrastructure. * Session-key records and delegated permission material needed for automation. * Idempotency records for write flows such as enrollment and withdrawal submission. These centralized systems are used to coordinate automation. They do not turn an integrator API key into a user wallet key, and they do not move user funds without the authorization path required by the relevant flow. ## What Is Not Centrally Managed Glider does not centrally manage: * Your end-user authentication or account recovery. * Your custody of your own API keys. * The user's root wallet, passkey, smart-wallet owner, or recovery policy. * A shared omnibus balance for your users. * Arbitrary withdrawals initiated only by an integrator API key. Your backend should treat the Glider API key like production infrastructure secret material: store it server-side, keep it out of browsers and mobile app binaries, restrict access internally, and rotate it if exposure is suspected. ## What Is Onchain The onchain layer is where asset custody and settlement occur: * Portfolio accounts are chain-specific smart accounts or managed account structures. * Deposits, balances, swaps, rebalances, and withdrawals settle onchain. * User signatures are verified against the expected owner for sensitive authorization flows. * Withdrawal authorizations are bound to the portfolio, recipient, assets, nonce, expiry, chain, and verifying contract. * For supported Solana/SVM flows, Glider uses a managed-account graph: the user's root authority bootstraps the managed account, and Glider receives scoped subordinate authority for automation. The API returns CAIP identifiers so integrators can reason about accounts and assets without relying on chain-specific field names. See [CAIP identifiers](/guides/caip-identifiers). ## Flow Example: Enrollment Enrollment is a two-stage authorization flow: 1. Your backend calls `POST /v2/enroll/signature` with the user's owner account, target strategy, and chains. 2. Glider verifies the strategy belongs to your tenant, resolves a managed automation agent, computes the smart-account session-key message, and returns the message plus round-trip fields. 3. The user signs the returned message in their wallet. 4. Your backend submits `POST /v2/enroll` with the original round-trip fields and the user's signature. 5. Glider verifies the signature, creates the portfolio and per-chain smart accounts, stores scoped session-key material, and schedules automation. Security properties: * The API key proves the request came from your tenant. * The user signature proves the owner wallet authorized enrollment. * `flowId` binds retries and prevents duplicate enrollment side effects. * Glider receives scoped automation authority, not the user's root key. See [Two-stage enrollment](/guides/two-stage-enrollment). ## Flow Example: Withdrawal Withdrawals are also two-stage: 1. Your backend calls `POST /v2/portfolios/{portfolioId}/withdraw/signature`. 2. Glider validates tenant ownership, recipient shape, chain match, duplicate assets, live balances, and portfolio smart-account availability. 3. Glider returns EIP-712 typed data with a short expiry and a random nonce. 4. The user signs the typed data. 5. Your backend submits the signed message to `POST /v2/portfolios/{portfolioId}/withdraw`. 6. Glider re-checks ownership, expiry, balances, recipient rules, and the signature before dispatching onchain execution. Security properties: * The signed message includes the portfolio, recipient, assets, nonce, expiry, chain, and verifying contract. * The nonce is the idempotency anchor for safe retries. * Expired or tampered authorizations are rejected. * The request is accepted asynchronously, then tracked through an operation id. See [Two-stage withdrawal](/guides/two-stage-withdrawal). ## Integrator Responsibilities Integrators are responsible for: * Keeping API keys server-side and limiting internal access. * Calling `GET /v2/whoami` during integration to confirm tenant identity and granted scopes. * Showing users exactly what they are signing and preserving returned signable payloads byte-for-byte between stages. * Mapping your user identity to the correct wallet or smart wallet. * Respecting idempotency anchors instead of generating new values on retry. * Handling `401`, `403`, `409`, `429`, and `5xx` responses according to the documented retry model. * Sending Glider the `X-Correlation-Id` from failing responses when asking for support. Start with [Authentication](/guides/authentication), [Idempotency](/guides/idempotency), and [Rate limiting](/guides/rate-limiting) for the operational pieces. ## Current Surface Notes The current v2 enrollment and withdrawal examples are EVM-oriented and use EVM wallet signatures, smart accounts, and EIP-712 where applicable. Glider's broader account model is cross-chain and uses CAIP identifiers throughout the API, with Solana/SVM support modeled through chain-native managed accounts and scoped delegation where supported. When in doubt, ask Glider which authorization path applies to your exact wallet stack before moving production traffic.