Bybit API error 110043: set leverage has not been modified

CoTrading editorial team 2026-09-23

Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs.

Bybit V5 returns retCode: 110043, documented as “Set leverage has not been modified.” In practice it usually means your call to POST /v5/position/set-leverage asked for the leverage the position already has. The state you wanted is the state you have. The fix: treat 110043 from set-leverage as success in code — matched by code, not message — and stop calling set-leverage when nothing needs to change.

This page is for anyone whose startup routine or order path sets leverage and sees 110043 show up as an error, or as an exception from their client library. It explains where the trigger description comes from, why the code is normally harmless, the cases where it is worth a second look, and a handler that does not swallow real failures.

What this error actually means

Bybit’s error page gives the code and its text, and nothing more about when it fires. The trigger description comes from a third party: CCXT issue #19396 documents 110043 being returned when set-leverage is called with the leverage already in effect, and records the live retMsg observed there as “Set leverage not modified” — slightly different wording from the documented “Set leverage has not been modified.”

That fits the code’s neighbours in Bybit’s table, which follow the same “not modified” pattern:

Code	Meaning (Bybit’s wording)
`110043`	“Set leverage has not been modified.”
`110025`	“Position mode has not been modified.”
`110026`	“Cross/isolated margin mode has not been modified.”

Each reads as “you asked for a change and there was nothing to change”. For 110025, that is switching to the mode the symbol is already in. We are relying on CCXT’s observation for 110043’s trigger; Bybit’s own docs we read do not spell it out.

The usual cause: setting leverage on every run

Most 110043s come from code that sets leverage unconditionally:

On every startup. The first run changes it; every run after returns 110043.
Before every order. A defensive set-leverage call ahead of each order returns 110043 on every order after the first.
On reconnect or restart loops, which re-run the startup path.

None of these are wrong in intent — making the leverage explicit is sensible. The only problem is the code treating the refusal as a failure.

Why it is normally harmless, and when it is not

If you asked for the value that is already set, the account is in the state you wanted. There is nothing to repair.

It deserves a second look in these cases, which are our editorial reading rather than anything Bybit documents:

You sent the wrong symbol or category. “Not modified” on the symbol you sent says nothing about the symbol you meant. Log both.
You expected a change. If the call was meant to lower leverage — for example, to reduce exposure after a loss — and it reports “not modified”, then the value you sent was already in place. Check that the value your code computed is the one you intended.
Hedge mode with different sides. Bybit’s rules: in one-way mode buyLeverage must equal sellLeverage; in hedge mode with isolated margin they may differ; in hedge mode with cross margin they must be equal. We did not find documentation of what set-leverage returns when one side already matches and the other does not. If that case matters to you, read the position back rather than assuming.

When in doubt, read the position record with GET /v5/position/list after the call and compare the leverage there with what you asked for. One extra read replaces an assumption with a fact.

Handling it in code

The goal: treat 110043 from this endpoint as success, and nothing else.

NOT_MODIFIED = 110043   # leverage already at the requested value

def ensure_leverage(post, symbol, lev):
    body = {"category": "linear", "symbol": symbol,
            "buyLeverage": str(lev), "sellLeverage": str(lev)}
    resp = post("/v5/position/set-leverage", body)   # your signed POST
    code = resp["retCode"]
    if code == 0:
        log.info("leverage set", symbol=symbol, lev=lev)
    elif code == NOT_MODIFIED:
        log.debug("leverage already set", symbol=symbol, lev=lev)
    else:
        raise LeverageError(code, resp["retMsg"])

Three details make this safe:

Match on retCode, not retMsg. The documented message and the one CCXT observed differ in wording. A string match on either will eventually miss.
Scope it to this call. 110043 means “not modified” only as a response to set-leverage. A generic “ignore these codes everywhere” list is how a real failure gets swallowed.
Know how your library surfaces it. Some clients raise an exception for any non-zero retCode. In that case, catch the exception around the set-leverage call, inspect the code it carries, and re-raise for anything other than 110043. Check how your particular client exposes the code rather than assuming.

Better still, avoid the call. Read the current leverage once at startup, keep it in memory, and call set-leverage only when the target differs. That also saves requests against the endpoint’s own rate limit — Bybit’s API limit is per account and per endpoint (see Bybit API errors 10006 vs 10018).

Choosing the value is the part that matters

The error is about bookkeeping. The number is about risk. Leverage does not, by itself, decide how much you can lose, but it decides how much margin a position ties up and how close the liquidation price sits to entry — see what is leverage and how leverage changes liquidation distance. Code that sets it should log the value it chose and why, so that a “not modified” can be checked against intent rather than ignored by habit.

The same idempotent pattern applies to position-mode changes: 110028 is a real blocker (open orders), while 110025 is the harmless “already in that mode”.

FAQ

What does Bybit error 110043 mean?

Bybit documents it as “Set leverage has not been modified.” According to CCXT issue #19396, it is returned when POST /v5/position/set-leverage requests the leverage that is already set, with a live message of “Set leverage not modified”. The account is already in the state you asked for.

Do I need to fix Bybit error 110043?

Usually not. If you asked for the leverage that is already in effect, nothing needs repairing; treat the response as success. It is worth checking that the symbol and value you sent were the ones you intended, especially if the call was meant to change leverage rather than confirm it.

Why does my client library throw an exception for 110043?

Many clients raise on any non-zero retCode, and 110043 is non-zero even though it describes a harmless state. Catch the exception around the set-leverage call only, check that the code is 110043, and re-raise anything else. Matching on the code is more reliable than matching on the message text.

Should I call set-leverage before every order on Bybit?

It is not necessary once the leverage is set, and every call uses the endpoint’s rate-limit budget and produces 110043 noise. Read the current leverage at startup, cache it, and call set-leverage only when your target value differs from what is in place.