Bybit TP/SL: Full vs Partial, Trigger Source and Reduce-Only

A stop is three decisions, not one

Attaching a stop loss on Bybit looks like a single action in the interface. Underneath, it is a choice about coverage, a choice about which price counts as “the price”, and a choice about what the order is allowed to do when it fires. The API exposes all three, which makes the trade-offs visible in a way the app hides.

The three settings are independent in principle and coupled in practice. Reading them in the right order avoids most of the ways a stop fails to do what its owner believed.

Coverage: Full or Partial

POST /v5/position/trading-stop takes a tpslMode parameter with two values.

Full attaches take profit and stop loss to the entire position. Bybit’s parameter table is explicit about the consequences: for tpslMode=Full, the exit order type is limited to market, so tpOrderType and slOrderType must be Market. There is no limit exit in Full mode at any parameter value. This is a design statement — the venue treats a full-position exit as a risk event that should complete, not as a resting order that might not fill.

Partial attaches a fixed size instead. Two parameters carry it: tpSize and slSize, and the documentation states that their values must be equal. That constraint surprises people who want a 30% take-profit and a 50% stop-loss from one position. On Bybit’s model that combination is two separate orders or it is not expressible through this endpoint at all.

Partial is also the only mode that accepts a limit price for the exit — tpLimitPrice and slLimitPrice are documented as working only when the mode is Partial and the corresponding order type is Limit. A limit exit has a real advantage (you pay the maker rate and control the fill price) and a real cost (in a fast move, it may not fill at all).

The two modes also differ in what can be changed afterwards. For Full, the endpoint can modify existing TP/SL parameters. For Partial, Bybit documents that the endpoint can only add partial position TP/SL orders. A strategy that needs to move a partial stop repeatedly should plan for cancel-and-replace rather than an update.

Position identity: one-way versus hedge

Every call also needs positionIdx, and the three allowed values are not interchangeable:

In one-way mode a position has one stop, because there is one position. In hedge mode the long and the short are separate positions that can coexist, and a stop attached with the wrong index lands on the wrong side. The visible symptom is a stop that exists in the response but does not appear next to the position the trader is looking at — and, later, a position that closes without the stop it was supposed to have.

An API client that stores “current position” as a single record will get this wrong the first time the account is switched to hedge mode. The position identity is a pair, not a scalar.

Trigger source: three prices that disagree

tpTriggerBy and slTriggerBy accept last price, index price and mark price. On a calm market they are within a few basis points of each other and the choice looks cosmetic. On the day it matters they are not.

• Last price is the most recent trade on this venue. It is what a chart shows, and it is the default for conditional orders on the order endpoint.
• Index price is a composite of prices across venues. It is designed not to move on a single venue’s wick.
• Mark price is the venue’s fair-price calculation, and it is the price used for liquidation. A stop placed relative to mark price is placed relative to the same number the risk engine uses.

The practical consequences run in both directions. A stop on last price can fire on a brief print that no other venue saw, closing a position that would have survived — the classic wick. A stop on mark price can sit untouched while last price trades far below it, because the composite did not move with this venue. Neither is wrong; they answer different questions. A position whose liquidation is computed on mark price, with a stop on last price, has a gap between the two mechanisms that is exactly the width of a wick.

Reduce-only and close-on-trigger

These two flags govern what an order is allowed to do, and they are frequently confused because both are described as “closing” orders.

reduceOnly means the position can only shrink if the order fills. Bybit’s documentation adds two important notes: it must be set to true when you are about to close or reduce a position, and when it is true, take profit and stop loss cannot be set on that order. A bot that builds a single order object with reduceOnly: true and a take-profit price will find the take profit silently absent from what the venue accepted.

closeOnTrigger is a stronger promise. It also can only reduce the position, and Bybit states that if the account has insufficient available balance when the order is triggered, other active orders on similar contracts are cancelled or reduced. The purpose is explicit: to ensure a stop reduces the position regardless of available margin.

That difference is the whole point. In a fast market, a stop that arrives when the account is already stressed can be rejected for margin — the position then runs, and the stop that was supposed to protect it becomes the thing that failed. A close-on-trigger order is designed to avoid exactly that outcome, at the cost of cancelling sibling orders you might have wanted.

For a strategy with several working orders around one position, those two behaviours imply different architectures. Plain stops preserve the rest of the ladder; close-on-trigger stops do not.

The ordering that avoids surprises

A stop configuration that survives contact with a real market usually follows this sequence:

1. Decide coverage first. Full position for a single exit, partial for a scaled exit. If a limit exit price matters, that decision forces Partial mode.
2. Set the trigger source per position. A stop whose purpose is to survive venue-specific wicks uses index or mark; a stop whose purpose is to track this venue’s traded price uses last.
3. Keep reduce-only and TP/SL in separate orders. They cannot coexist on one order, and the rejection is not always loud.
4. Use close-on-trigger when margin stress is the scenario you are insuring against, and accept that sibling orders for the same contract may be cancelled when it fires.
5. Verify by reading back. Query the position’s TP/SL after setting it, in the same position mode you set it in. A response that echoes the request is not the same as a book that contains the stop.

The failure mode the sequence is built to avoid is subtle: a stop that exists, is acknowledged, and is attached to the wrong position index or the wrong price source — so it looks present on every dashboard and does nothing on the day it is needed.

Two neighbouring mechanics complete the risk picture. Liquidation on Bybit is computed against maintenance margin, and the distance between the stop and the liquidation price is the buffer that decides which one fires first — covered in maintenance margin and margin calls. When a position is closed by the engine rather than by your stop, the counterpart is the auto-deleveraging queue, which Bybit’s ADL and insurance fund walks through. And the generic question of whether a stop should be a limit or a market order is the subject of stop-limit versus stop-market, which on Bybit maps directly onto the Full and Partial modes.

Risk note. Modes, parameter constraints, trigger types and flag interactions in this article were read from Bybit’s V5 API documentation on 2026-10-30. Venue parameters change; the distinction between coverage, trigger source and order permission does not. Nothing here is investment advice.