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 toPOST /executeAction; a client-only session step is completed directly by the provider plugin.
Request Body
Request Fields
Action Types
MarketRef
Many action params use amarket 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 acceptedmode 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
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 viagetOrder — there is no LI.FI HTTP endpoint. The returned Order shape:
Order Schema
Order Status Values
SDK:
getOrder()