Skip to main content
Glider separates reusable investment logic from end-user accounts:
  • A strategy defines an allocation, rebalance schedule, and preferences.
  • A portfolio enrolls one end user into a strategy and exposes a smart account for each active chain.
  • An operation tracks asynchronous work such as a rebalance or withdrawal.
All routes below are relative to https://api.glider.fi/v2 and authenticate with the x-api-key header.
Keep GLIDER_API_KEY on your backend. Send only Glider’s signable payload to the user’s wallet.

​
Before you start

If you do not have a key, request B2B API access. Then confirm its tenant and scopes:
Most integrations need strategies:read, enroll:write, portfolios:read, and portfolios:write. To create strategies, you also need strategies:write. To withdraw assets, you need portfolios:withdraw.

​
Lifecycle map

​
1. Create or surface a strategy

Create a tenant-owned strategy with POST /v2/strategies, list your existing strategies with GET /v2/strategies, or surface eligible public strategies with GET /v2/discovery/strategies. Allocations use CAIP-19 asset IDs and string percentages totaling 100. Schedules support interval frequencies or five-field cron expressions with an IANA timezone. Publishing a new strategy version updates the target used by enrolled portfolios on their next rebalance.

​
2. Enroll the end user

Enrollment is a user-authorized, two-stage flow:
  1. Call POST /v2/enroll/signature.
  2. Have the user sign the returned ECDSA, ERC-1271, or Solana payload.
  3. Submit the unchanged round-trip fields and signature to POST /v2/enroll.
The response includes the portfolioId and chain-bound smartAccounts. See Two-stage enrollment for exact request and wallet-signing shapes.

​
3. Fund the portfolio

The B2B API does not expose a deposit-builder route. Transfer supported assets using the user’s wallet or custody provider:
  1. Select the smart account whose CAIP-10 chain matches the asset.
  2. Use depositAccountId when the smart-account object provides one.
  3. Submit the asset transfer onchain.
  4. Verify it through GET /v2/portfolios/{portfolioId}/positions.
See Fund a portfolio for the complete flow.

​
4. Start and monitor automation

Start or resume the schedule with POST /v2/portfolios/{portfolioId}/start. Read GET /v2/portfolios/{portfolioId} for its status, cadence, nextDueAt, and lastRebalanceAt. For an immediate run, call POST /v2/portfolios/{portfolioId}/rebalance. Poll the returned operationId every 2–5 seconds until it is completed, failed, or cancelled. Use /positions for live balances, /performance for historical returns, and /sector-exposure for equity-sector aggregation.

​
5. Withdraw or liquidate

Withdrawals require a fresh owner authorization:
  1. Call POST /v2/portfolios/{portfolioId}/withdraw/signature.
  2. Have the owner sign the returned authorization.
  3. Submit the inner message and signature to POST /v2/portfolios/{portfolioId}/withdraw.
  4. Poll the returned operation.
Use /liquidate-all/signature and /liquidate-all to swap eligible holdings to a same-chain settlement asset before delivery. Withdrawal authorizations expire after 10 minutes.

​
Retry safely

Fix 400, 401, and 403 responses before retrying. Honor Retry-After on 429, retry transient 5xx responses only when the operation is idempotent, and reuse stage-two idempotency anchors and signed bodies verbatim.

​
Continue with the integration guides