# Split a take-profit across several targets

A single take-profit is all-or-nothing. Swapping `tpPrice` for `tpLegs` on the same endpoint
gives you up to three rungs — each a reduce-only limit at its own price and size — sharing
one OCO group with the stop, so the stop still covers whatever is left.

1. ### Size the rungs against the position

   You compute the split; the server does not. Read the live size first and divide it — for
   `0.9 BTC` in thirds, three rungs of `0.3`.

   ```bash
   curl -s https://api.troncharts.xyz/api/v1/accounts/$ACCOUNT_ID/positions \
     -H "authorization: Bearer $TOKEN" \
     -H "x-tenant-slug: $TC_TENANT_SLUG"
   # → { positions: [ { symbol: "BTC.HL", qty: "0.9", … } ] }
   ```

   The rung quantities are read as RATIOS, not absolute sizes. The server re-sizes the
   ladder against the live position, so a set that sums to more than the position is scaled
   down rather than over-closing, and a rung the position cannot fund is dropped instead of
   being sent as a zero. Send `sizedAgainstQty` when your ratios were computed against a
   different size — without it the ladder is read as covering the whole position.

2. ### Attach the ladder

   `tpLegs` takes one to three entries, each with a required positive `price` and `qty`. It
   is mutually exclusive with `tpPrice`. `tag` is optional (`tp1` / `tp2` / `tp3`) and is
   display metadata only — the OMS does not persist it, so the functional split is the
   price and qty you send.

   ```bash
   curl -s https://api.troncharts.xyz/api/v1/oms/brackets/attach-to-position \
     -H "authorization: Bearer $TOKEN" \
     -H "x-tenant-slug: $TC_TENANT_SLUG" \
     -H 'content-type: application/json' \
     -H "idempotency-key: $(uuidgen)" \
     -d '{
       "symbol": "BTC.HL",
       "tpLegs": [
         { "price": 68000, "qty": 0.3, "tag": "tp1" },
         { "price": 72000, "qty": 0.3, "tag": "tp2" },
         { "price": 78000, "qty": 0.3, "tag": "tp3" }
       ],
       "slPrice": 58500
     }'
   ```

3. ### Read the per-leg intent ids

   `tpIntentIds` is the array you want — one id per rung, in the order you sent them.
   `tpIntentId` (singular) is back-compat and only ever carries the **first** rung. The
   response `qty` is the full protected position size, not a per-rung number.

   ```json
   { "ok": true, "ocoGroupId": "9c41…",
     "tpIntentId": "1a2b…",
     "tpIntentIds": ["1a2b…", "4c5d…", "6e7f…"],
     "slIntentId": "7d8e…", "side": "sell", "qty": "0.9" }
   ```

   :::note[Rungs re-size themselves]
   Each leg is stamped with the position size it was sized against (`sizedAgainstQty`). When
   the position later grows or shrinks the server re-sizes every rung fraction-preserving —
   a one-third rung stays one-third — instead of inflating it to full cover.
   :::

   :::caution[REST only]
   The TypeScript SDK's `AttachToPositionBody` declares `symbol`, `tpPrice` and `slPrice` and
   has no `tpLegs`, and its response type has no `tpIntentIds`. Call this one over REST until
   the SDK catches up.
   :::

**Next:** [Attach a take-profit and stop-loss](https://docs.troncharts.xyz/docs/recipes/attach-a-bracket/) · [Cancel an order or close a position](https://docs.troncharts.xyz/docs/recipes/cancel-and-flatten/) · [Orders & OMS](https://docs.troncharts.xyz/docs/trading/orders/)