B2B API Overview

The B2B API separates four types of authority:

Integrator API keys identify the tenant. They let your backend create strategies, enroll users, and read portfolios. Each key can use only its assigned scopes.
Users control their wallets and portfolios. Enrollment and withdrawal flows require user signatures. An API key cannot replace a user signature.
Glider manages permitted automation. Glider uses session keys or delegated agents to run scheduled and manual rebalances.
Assets stay onchain. User-specific smart accounts hold portfolio assets. Glider does not use an omnibus offchain ledger for these assets.

For more information, read Glider’s Security Architecture. Contact the Glider team if you have questions about your wallet provider or production rollout.

Choose your integration role

You can use the B2B API as a strategy provider, a distributor, or both.

Role	What you manage	Start here
Strategy provider	Create reusable strategies and manage their allocations, schedules, and visibility	Becoming a Strategy Provider
Distributor	Surface strategies to users, enroll users, fund portfolios, and manage portfolio operations	Becoming a Strategy Distributor
Provider and distributor	Create strategies and integrate the complete user portfolio lifecycle	Quickstart

Portfolio authority model

Three authority layers can affect each user-instantiated portfolio and its smart accounts:

Authority layer	Controlled by	What it can do
B2B tenant	Your backend with a scoped API key	Request permitted portfolio lifecycle actions and read the resources allowed by the key’s scopes
End-user root authority	The end-user wallet, smart wallet, or passkey root where supported	Authorize enrollment, retain ownership of the smart accounts, and approve withdrawals
Glider automation	Glider-managed agents and scoped session keys	Rebalance portfolio holdings within the permissions that the user granted for that portfolio

This model describes authority over user portfolios and smart accounts, not control of the B2B integration itself. The API key controls access to B2B API resources. It does not grant custody of user assets or root control of a user’s smart accounts.

Systems that Glider manages

Glider operates these offchain systems:

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 permissions.
Idempotency records for write flows such as enrollment and withdrawal submission.

These systems coordinate automation. An integrator API key does not give access to a user wallet. Glider moves funds only through the applicable authorization flow.

Systems that Glider does not manage

Glider does not control:

Your end-user authentication or account recovery.
The storage of your API keys.
The user’s root wallet, passkey, smart-wallet owner, or recovery policy.
A shared omnibus balance for your users.
Withdrawals that use only an integrator API key.

Store the Glider API key on your backend. Do not put it in a browser or a mobile application. Limit internal access to the key. Rotate the key if you think that it is exposed.

Onchain functions

The following functions occur onchain:

Portfolio accounts are chain-specific smart accounts or managed account structures.
Deposits, balances, swaps, rebalances, and withdrawals settle onchain.
Sensitive authorization flows verify the signature of the expected owner.
Withdrawal authorizations are bound to the portfolio, recipient, assets, nonce, expiry, chain, and verifying contract.
Supported Solana flows use a managed-account graph. The user creates the managed account. Glider receives limited authority for automation.

The API returns CAIP identifiers for accounts and assets. Thus, you do not need chain-specific field names. See CAIP identifiers.

Your responsibilities

All integrators must:

Keep API keys on your backend and limit internal access.
Call GET /v2/whoami to confirm the tenant identity and the assigned scopes.
Handle errors as specified in the retry model.
Send the X-Correlation-Id to Glider when you request support.

For role-specific responsibilities, see Becoming a Strategy Provider and Becoming a Strategy Distributor. Create and manage B2B API keys in the Glider Console. Then, read Idempotency and Rate limiting.

Strategy creation example

A strategy provider creates a reusable allocation and rebalance schedule. This example creates a private strategy with USDC and WETH targets:

const response = await fetch("https://api.glider.fi/v2/strategies", {
  method: "POST",
  headers: {
    "content-type": "application/json",
    "x-api-key": process.env.GLIDER_API_KEY,
  },
  body: JSON.stringify({
    name: "Balanced Growth",
    description: "60% USDC and 40% WETH",
    allocation: {
      assets: [
        {
          assetId:
            "eip155:1/erc20:0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
          weight: "60",
        },
        {
          assetId:
            "eip155:1/erc20:0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
          weight: "40",
        },
      ],
    },
    schedule: { type: "interval", frequency: "daily" },
    isPublic: false,
  }),
});

const created = await response.json();
if (!response.ok) {
  throw new Error(created.error.message);
}

const strategyId = created.data.strategyId;

The API key requires strategies:write. Store the returned strategyId; it stays the same across future allocation versions. See Build and Distribute Strategies for validation, updates, and distribution.

Enrollment example

Enrollment is a two-stage authorization flow:

Your backend calls POST /v2/enroll/signature with the user’s owner account, target strategy, chains, and optional accountType.
Glider verifies that your tenant can enroll users in the strategy.
Glider selects an automation agent and returns the wallet authorization payload with the round-trip fields.
The user signs the required message or transaction in their wallet.
Your backend sends the signed artifact and the original fields to POST /v2/enroll.
Glider verifies the authorization and creates the portfolio and smart accounts.
Glider starts portfolio automation.

The flow has these security properties:

The API key identifies your tenant.
The user signature authorizes enrollment.
accountType selects the Kernel sudo validator: omitted/ECDSA for EOA owners, or ERC1271 for supported smart-contract wallets.
flowId prevents duplicate enrollment effects during retries.
Glider receives limited automation authority. Glider does not receive the root key of the user.

See Two-stage enrollment.

Withdrawal example

Withdrawals use two stages:

Your backend calls POST /v2/portfolios/{portfolioId}/withdraw/signature.
Glider validates the tenant, recipient, chain, assets, and balances.
Glider returns EIP-712 typed data with an expiry and a random nonce.
The user signs the data.
Your backend sends the signed message to POST /v2/portfolios/{portfolioId}/withdraw.
Glider checks the request again.
Glider starts the onchain operation.

The flow has these 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.
Glider rejects expired or changed authorizations.
Glider accepts the request asynchronously and returns an operation ID.

See Two-stage withdrawal.

Supported owner models

The enrollment and withdrawal flows support EVM and Solana owner models. EVM flows use ECDSA or ERC-1271 signatures and Kernel smart accounts. Solana flows use chain-native signatures and Swig managed accounts. The svm_b2b_api entitlement controls access to Solana flows. Both owner models use CAIP identifiers at the API boundary. Ask Glider which authorization path applies to your wallet stack. Do this before you send production traffic.

Get Started

Understanding the Glider Platform

For Strategy Providers

For Strategy Distributors

Advanced

Wallet Providers

Choose your integration role

Portfolio authority model

Systems that Glider manages

Systems that Glider does not manage

Onchain functions

Your responsibilities

Strategy creation example

Enrollment example

Withdrawal example

Supported owner models

​Choose your integration role

​Portfolio authority model

​Systems that Glider manages

​Systems that Glider does not manage

​Onchain functions

​Your responsibilities

​Strategy creation example

​Enrollment example

​Withdrawal example

​Supported owner models

Choose your integration role

Portfolio authority model

Systems that Glider manages

Systems that Glider does not manage

Onchain functions

Your responsibilities

Strategy creation example

Enrollment example

Withdrawal example

Supported owner models