Skip to main content
All mutating operations follow the create -> sign -> execute pattern through two unified endpoints. The action field determines the operation.
These endpoints are intended to be used via @lifi/perps-sdk. The typed data signing and submission flow is complex and best handled by the SDK.

POST /createAction

Build provider-specific authorization steps. Signed EIP-712, WASM, EVM, HMAC, and SIWE steps continue to POST /executeAction; a client-only session step is completed directly by the provider plugin.

Request Body

Request Fields

Action Types

MarketRef

Many action params use a market field with the MarketRef type:

PlaceOrderParams

TriggerOrderInput:

PlaceTriggerOrderParams

Place standalone TP/SL on an existing position.

PlaceTwapOrderParams

Place a TWAP parent order that executes over a fixed duration. market, side, size, durationSeconds, and reduceOnly are provider-independent; the remaining fields are extras honoured only by the provider that advertises them on its placeTwapOrder action’s params descriptors (GET /providers) — a provider that does not advertise an extra ignores it.

CancelOrderParams

CancelTwapOrderParams

ModifyOrderParams

Each ModifyOrderInput:

UpdateLeverageParams

UpdatePositionMarginParams

WithdrawalParams

ApproveAgentParams

AccountModeParams

Generic account-level operating-mode switch (e.g. Hyperliquid abstraction variants, Lighter UTA / Simple). The accepted mode values are provider-specific — read them from the corresponding setup / options descriptor on GET /providers (the descriptor’s params[].values array enumerates them). @lifi/perps-types intentionally does not encode the per-provider value list, so providers can add new modes without a types release.

AccountTypeParams

Generic account-level fee/latency tier switch (e.g. Lighter standard / premium). Providers without tiering omit the action entirely.

CancelAllOrdersParams

RegisterApiKeyParams

DepositParams

SendAssetParams

Response 201

ActionStep is a discriminated union by structural shape — the variant depends on the action’s signingMethod on the provider descriptor: All variants carry the same action field (the ActionType from the request). The example above shows the EIP-712 variant; the wasmBlob variant carries wasmSignParams and the evmTx variant (e.g. deposit) carries txParams in place of typedData. HmacActionStep and SiweActionStep are signed and submitted via executeAction; a SessionActionStep carries no signable material — the SDK performs the venue call directly with its session token and skips executeAction.

Response 400

Validation error.

POST /executeAction

Submit signed payloads from /createAction.

Request Body

SignedActionStep mirrors ActionStep as a discriminated union — each variant carries the original payload plus its signed artefact: The example above shows the EIP-712 variant. Submit signed steps in the same shape and order they were returned by /createAction. SessionActionSteps are not submitted here — they carry no signable material, so the SDK executes them client-side against the venue and skips /executeAction.

Response 202

Each ActionResult:

Response 400

Validation error.

Response 401

Authentication error (invalid signature).

Response 422

Insufficient margin for the order.

Order details (SDK)

Single-order lookup is served by the SDK directly from each provider via getOrder — there is no LI.FI HTTP endpoint. The returned Order shape:

Order Schema

Order Status Values

SDK: getOrder()