Skip to main content
Use positions:modify to submit a supported change and read to obtain current state. MODIFY is a complete intended PositionRequest, not JSON Patch and not a replay of the original OPEN request.

Read the current publication

This returns success/message/data, where data is the current Position publication, not a ready-made request. Construct the intended request from current rows and protection configuration. Keep the returned revision, current slot_id values and exact internal physical order_id values.

Build one explicit change

  1. Preserve position_side, margin mode, link, instrument and eligible spot settlement configuration.
  2. Preserve every existing OPEN and TP row that should remain, including its current slot identity and current quantity/price semantics after fills.
  3. Change only the intended configuration. If targeting an existing physical order, include its exact order_id in order_amendments.
  4. Omit unchanged leverage to avoid an unnecessary leverage preflight.
  5. Set outer expected_revision to the freshly observed positive revision.
  6. Allocate a new client command ID for this modification and persist the complete request.

Full modification example

This synthetic example assumes a current revision of 7 and one current OPEN and TP slot. It changes the static SL to 69,000 and disables SLx while retaining the pictured opening and TP rows. The placeholders are not valid live slot identities. Use this only if a fresh publication actually matches the assumed rows and quantities.
Download the illustrative modify-command.json. The current row values are essential; the file is not a generic template to replay after arbitrary fills.

Amend one physical order

Inside the complete request, a targeted amendment can have this shape:
This is a fragment, not a complete command. It must correspond to the current physical order generation and the intended row configuration. Never substitute a venue order ID, assume an old successor is current or amend using a stale cached snapshot.

Cancel a pending attached row

There is no external arbitrary-order cancellation endpoint. Supported attached-row removal is expressed through a complete current modification and its retained slot list, subject to the existing lifecycle rules. Omitting a current slot can request cancellation; therefore accidental omission can have trading consequences. Do not remove filled rows or reconstruct a configuration from historical OPEN JSON. To stop the entire lifecycle, use terminate. It also handles a pending-to-filled race; a client-side “still pending” observation cannot guarantee that exposure remained zero.

Conflicts and uncertainty

A stale revision is a conflict. Read a fresh publication, reassess the intended change, and create a deliberately new command. Do not automatically substitute the new revision into an old request; rows, fills and protection references may also have changed. A timeout after submission is not a rejection. Preserve the same identity for a transport retry and inspect the receipt. operator_required means the available evidence does not safely resolve side effects; do not replay the whole modification or submit compensating trades. The execution owner preserves cancellation-barrier registration, dispatches cancellation without holding the position lock, checks the exact generation, then reconciles fresh state before replacement and protection work. Clients must not precompute a replacement plan across that boundary. Leverage preflight may precede a later revision or cap rejection. A modification is not an atomic transaction across the exchange and Liftx state; receipts distinguish uncertain side effects.

TradingView limitation

Advanced Pine can express the full payload, but cannot retrieve the current Liftx publication or consume the webhook result. TradingView capped MODIFY must preserve OPEN rows. State-dependent OPEN amendments, conflict reconciliation and multi-position workflows belong in an API controller with current read access. There is no blind group MODIFY.