Skip to main content
POST
/
v2
/
portfolios
/
{portfolioId}
/
liquidate-all
curl --request POST \
  --url 'https://api.glider.fi/v2/portfolios/a1b2c3d4/liquidate-all' \
  --header 'x-api-key: gldr_sk_your_api_key' \
  --header 'Content-Type: application/json' \
  --data '{
    "message": {
      "portfolioId": "a1b2c3d4",
      "recipientAccountId": "eip155:1:0x4444444444444444444444444444444444444444",
      "assets": [
        {
          "assetId": "eip155:1/erc20:0x6b175474e89094c44da98b954eedeac495271d0f",
          "amountRaw": "5000000000000000000"
        }
      ],
      "nonce": "0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef",
      "expiresAt": 1744898400,
      "liquidate": true,
      "settlementAssetId": "eip155:1/erc20:0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"
    },
    "signature": "0xabc..."
  }'

{
  "success": true,
  "data": {
    "operationId": "op_01JWZEE2MF30KVRMRX53N88VA4",
    "submittedAt": "2026-04-17T12:05:00.000Z"
  }
}
Stage 2 of the two-stage liquidate-all flow. Accepts the message returned by POST .../liquidate-all/signature verbatim, plus the owner’s signature. Verifies ownership, re-checks live balances, and dispatches the swap to the settlement asset + delivery to the recipient. This is functionally identical to POST .../withdraw submitting a liquidate: true authorization — same verification, idempotency (keyed on message.nonce), and polling. Echo the stage-1 message back as body.message (typedData.message for EVM portfolios, authorization.message for Solana); the liquidate: true flag and the settlementAssetId settlement asset must be present and are part of the signed bytes.
  • Auth: x-api-key header (required)
  • Scope: portfolios:withdraw
  • Chains: EVM and Solana (Solana requires the tenant’s Solana B2B API access — without it, a Solana recipient returns 403).

​
Polling for onchain status

The response returns operationId. Poll GET /v2/portfolios/{portfolioId}/operations/{operationId} until the operation reaches a terminal (completed / failed / cancelled) state. The operation tracks the swap that produces and delivers the settlement asset.

​
Solana portfolios

A Solana liquidation runs as one engine operation: every authorized asset is swapped to USDC inside the portfolio’s smart account (Jupiter routing), and the combined proceeds — the swap outputs plus any USDC the portfolio already held — are then transferred to the recipient in a final leg. Nothing leaves the smart account until every swap has settled, so a failed liquidation keeps all value inside the portfolio and a fresh authorization retries cleanly (already-swapped USDC simply becomes part of the next liquidation’s direct transfer). Native SOL is liquidated too, minus a small rent reserve that keeps the account rent-exempt.

​
Portfolios holding Ondo tokenized stocks

Ondo Global Markets tokens (tokenized stocks such as TSLAon, SPCXon) are liquidated through Ondo’s direct redemption — not on-market swaps — for materially better pricing. All Ondo holdings are redeemed in a single batched settlement and the proceeds are delivered to the recipient in the settlement asset. Two consequences:
  • Settlement asset constraint. Ondo redemption settles in the chain’s Ondo cash asset: USDT on BNB Chain (56), USDC on Ethereum (1). A liquidation of a portfolio holding Ondo tokens with any other settlementAssetId is rejected at stage 1 with 400 API_221 UNSUPPORTED_SETTLEMENT_ASSET, before anything is signed. To exit to a different stable, withdraw the Ondo tokens in-kind via POST .../withdraw instead.
  • Market hours. Redemption requires an open US equities session. Submissions outside market hours (or during a halt) are accepted (202) but the redemption operation can fail after retries with an Ondo market-closed error — resubmit during regular trading hours.
When Ondo assets are present, the returned operationId tracks the redemption operation (the slowest leg). Any same-chain transfer of an existing settlement-asset balance and any swap of non-Ondo assets dispatch as separate engine operations under the same authorization.

​
Common error responses

Identical to POST .../withdraw, including 400 API_219 WITHDRAW_AS_USDC_UNSUPPORTED_CHAIN when the default USDC settlement asset is unavailable on the recipient’s chain and 400 API_221 UNSUPPORTED_SETTLEMENT_ASSET when message.settlementAssetId is not an allowed settlement asset on the chain (USDC or USDT on EVM; USDC on Solana), plus the shared expiry / signature / idempotency errors. 
curl --request POST \
  --url 'https://api.glider.fi/v2/portfolios/a1b2c3d4/liquidate-all' \
  --header 'x-api-key: gldr_sk_your_api_key' \
  --header 'Content-Type: application/json' \
  --data '{
    "message": {
      "portfolioId": "a1b2c3d4",
      "recipientAccountId": "eip155:1:0x4444444444444444444444444444444444444444",
      "assets": [
        {
          "assetId": "eip155:1/erc20:0x6b175474e89094c44da98b954eedeac495271d0f",
          "amountRaw": "5000000000000000000"
        }
      ],
      "nonce": "0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef",
      "expiresAt": 1744898400,
      "liquidate": true,
      "settlementAssetId": "eip155:1/erc20:0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"
    },
    "signature": "0xabc..."
  }'

{
  "success": true,
  "data": {
    "operationId": "op_01JWZEE2MF30KVRMRX53N88VA4",
    "submittedAt": "2026-04-17T12:05:00.000Z"
  }
}