Bybit FIX API Overview

TL;DR

Bybit launched a FIX API for spot trading on 1 September 2026. It is a FIX 4.4 session over persistent TLS, reachable at fix-oe.bybit.com:9000, and access is granted per account by whitelist rather than by creating a key. The documented launch scope is new order, amend and cancel. For an integrator, three design choices matter more than the field tables. The session has no message recovery, cancel and amend rejects arrive without order identifiers, and several message types and tags are Bybit's own, so an off-the-shelf engine configuration will not parse the feed as shipped.

What landed on 1 September 2026

Verified October 2026. These are the values most likely to change.

The launch date and scope appear in Bybit's API announcements channel; the V5 changelog, which carries dated REST API, WebSocket API and SBE API sections, has no FIX API section as of October 2026, and its only FIX-related entry is the isFixApi field added to Get API Key Information on 2026-09-01.

You cannot self-serve your way in

Creating an API key is not enough. FIX access requires whitelist onboarding at either UID or institutional ID (ins_id) granularity, requested through a Bybit relationship manager. The announcement frames the product for VIP and institutional clients.

Integration can begin before that conversation concludes. The announcement lists testnet as available ahead of the mainnet date, and the testnet session runs at fix-oe-testnet.bybit.com:9000 with keys created on the testnet site. The integration guide states the whitelist requirement without distinguishing testnet from mainnet, so whether the testnet session is gated the same way is not answered on that page.

An account that is not whitelisted fails at the session layer, not at the application layer. The server accepts the TCP and TLS connection, reads a correctly signed Logon (A), and then terminates the session with Logout (5) carrying Text (58) = access denied. An integration that treats any Logout during startup as a transient network condition will keep retrying against a permission error.

Key material is also constrained. Only self-generated RSA keys work: the key is created by selecting the self-generated option, uploading an RSA public key of 2048 or 4096 bits, and enabling FIX API on the key. Signing is RSA-SHA256 over the string "GET/realtime" + expires, where expires is a Unix millisecond timestamp, base64-encoded into RawData (96), with the same value repeated in Expires (30023). HMAC keys, which work for REST V5, do not apply here.

What the session carries

The announcement scopes the launch to new order, order amend and order cancel, and Category (30010) is required on every order message and must be spot.

The message types reference on the integration guide lists twelve types: 0, 1, 3, 5, A for session management, and D, F, 8, XAR, XCA, XAA, j for application traffic. A desk moving an existing FIX integration across will keep its REST or WebSocket plumbing for everything outside the published scope of new order, amend and cancel.

The session has no message recovery, and that failure is silent

Bybit does not implement the FIX 4.4 gap-fill mechanism: ResendRequest (2) and SequenceReset (4) are not supported. MsgSeqNum restarts from 1 on every connection, the server forcibly resets the sequence on each new session, and clients are advised to send ResetSeqNumFlag (141) = Y in Logon to keep both sides aligned. Session resume on reconnect is not supported, and messages that were unconsumed at the moment of disconnect are not retransmitted on the next connection.

Together these rules produce one failure mode: an execution that occurred while the socket was down is not replayed when the socket comes back. The FIX session will look healthy — new sequence, clean logon, orders flowing — while the client's order state is wrong. Nothing in the protocol flow signals the gap. Bybit's FIX API documentation does not describe a replay path, so state has to be rebuilt from outside the FIX session.

Two session rules decide how quickly a client can come back:

• HeartBtInt (108) is required in Logon but is fixed to 10 seconds server-side, and any client-supplied value is overridden. The server's own Logon response returns 108=10.
• Only one active connection per SenderCompID is allowed at a time, and a client that disconnects without sending Logout (5) blocks that SenderCompID from establishing a new session for 3 × HeartBtInt, which the documentation states as 30 seconds.

An ungraceful disconnect therefore costs a 30-second blackout on that SenderCompID on top of the lost messages. A desk that wants faster failover needs a second SenderCompID ready, which the connection model allows: one UID may open concurrent connections under multiple distinct SenderCompIDs.

Bybit does publish a dead man's switch, and it is built on a different connection. Disconnection Protect cancels all active futures, spot and option orders when the client fails to reconnect and resume its heartbeat inside a window that defaults to 10 seconds and is configurable from 3 to 300 seconds. The mechanism rests on the private WebSocket connection and its heartbeat, and that WebSocket connection must subscribe to the dcp topic for DCP to trigger. It is turned on through a client manager and is available to institutional clients only, with VIP clients excluded, while the FIX launch is addressed to VIP and institutional clients alike. None of the five pages in the FIX API documentation section mentions DCP or any cancel-on-disconnect behaviour, so how a dropped FIX session interacts with it is a question for the relationship manager who grants access — worth settling before go-live rather than during a reconnect on mainnet.

Cancel and amend rejects arrive without the identifiers you correlate on

An order reject (ExecType=8) omits both OrderID (37) and ClOrdID (11); the documentation says to correlate rejects to requests via ReqId (30006) or by send order.

Cancel and amend rejects go further. OrderCancelAck (XCA) and OrderAmendAck (XAA) omit 150, 39, 37 and 11 on rejection, leaving OrdRejReason (103) and Text (58) as the only content; the documentation's guidance is to correlate rejects to requests by send order. An XAA that lacks 150/39 but carries 103/58 is the shape of a rejected amend.

ReqId (30006) is the intended correlation key, and its scope is narrow: it is echoed on the synchronous ack — the PendingNew ExecutionReport, XCA, XAA — and is not carried on asynchronous state pushes such as ExecType=0, 4 or F. The same applies to the rate-limit header fields, which appear on the initial ack only and are omitted from subsequent state pushes.

ClOrdID (11) carries the client order ID, is capped at 36 characters, and is scoped to the account (UID) rather than to the session: an ID held by an active order cannot be reused, and IDs belonging to terminated orders become eligible for reuse after 360 days. Concurrent sessions under one UID therefore draw from a single namespace, which an ID generator keyed on the session does not account for.

OrdRejReason (103) carries Bybit's internal error codes rather than FIX enumerations: 170140 for an order value below the minimum, 10001 in the documented example of an amend that changes nothing, 170213 for an order that does not exist. On the terminal cancel push the same tag carries a string, EC_PerCancelRequest, alongside CancelType (30040) = CancelByUser. One tag therefore carries two shapes of value, and a parser that assumes a single shape will meet the other.

Your engine needs a custom dictionary

Bybit's amend is AtomicReplaceRequest (XAR); the standard FIX OrderCancelReplaceRequest (G) is not supported. Acks for cancel and amend are XCA and XAA. Bybit documents all three as its own message types, so an engine has to be told about them before it will accept them.

The extension fields are Bybit's own too. The session carries ResponseMode (25036) in Logon and a block of Bybit header fields in the 30001–30009 range on every message, including ReqId (30006), BapiTimestamp (30002), BapiRecvWindow (30001), TraceId (30005) and three rate-limit fields. Order and execution messages add fields up to 30066.

Three parsing details are stated in the documentation:

• BapiTimestamp (30002) and BapiLimitResetTimestamp (30009) are 64-bit integers, and the documentation warns that FIX libraries defaulting to 32-bit INT parsing will mis-read them.
• The fill details group uses NoFills (30050) as the count and FillExecID (30051) as the delimiter tag, with every entry starting on 30051. The fee group uses NoFeeDetails (30060) with FeeCoin (30061) as its delimiter.
• Field order inside a group entry is fixed. Optional fields may be omitted but their relative position is not free, and the documentation names QuickFIX and Onix as order-sensitive engines that will raise a parser error on out-of-order tags.

Order typing is arranged differently as well. OrdType (40) accepts only 1 (Market) and 2 (Limit). Conditional orders are expressed through OrderFilter (30024) with values Order, tpslOrder or StopOrder, plus StopPx (99), and the trigger direction is derived by the system from the order side and the trigger price relative to the market rather than being specified by the client.

The rate limit budget is the same as REST

The FIX API uses the same rate limit pool as REST V5. Remaining weight is reported in BapiLimit (30007), BapiLimitStatus (30008) and BapiLimitResetTimestamp (30009), and when remaining weight reaches 0 requests are rejected until the window resets, returning an ExecutionReport with ExecType=8 and the reason in Text (58).

What FIX changes is the shape of the connection rather than the budget. The case for moving is lower per-request overhead and reuse of existing FIX infrastructure, not a higher ceiling.

Several connections mean several copies of the same event

ResponseMode (25036) in Logon selects what the server pushes: 1 (Everything) delivers order acks, fill reports and passive status updates and is the default; 2 (OnlyAcks) suppresses passive pushes and returns only direct responses to the client's own requests.

When one UID holds several concurrent FIX connections, passive pushes — a fill on an order placed over REST, or a state change caused by another session — are broadcast to every connection in ResponseMode=1, not only to the most recent one, and deduplication is the client's responsibility.

Ordering carries its own caveat. The documentation states two things side by side: MsgSeqNum is strictly monotonic within a session, and in Everything mode a new order produces both a PendingNew report and a New report, which may arrive out of order. A state machine that assumes A always precedes 0 needs to tolerate the reverse.

Where Bybit's spot FIX departs from a stock FIX 4.4 setup

Bybit names the departures itself in two places: it says it does not implement the standard FIX 4.4 gap-fill mechanism, and that the standard OrderCancelReplaceRequest (G) is not supported. The rest of this table records what its own pages document, area by area.

Where Axon Trade fits

Axon Trade is a connectivity and normalization layer that gives a trading system one slightly modified FIX 4.4 integration and routes it to more than 30 exchanges, with two session types — trading and market data — each carrying its own message set. One trading session is the entry point for all of an organization's accounts and exchanges, with ACL rules controlling which logins may send to which destinations.

One practical difference for an integrating desk is which dialect the engine has to speak. On the Axon session the amend is the standard OrderCancelReplaceRequest (G), and the symbol is the canonical slash form such as ETH/USDT, identical for market data and execution across venues. Bybit instruments are addressed in that normalized form — BTC/USDT for spot and PERP:BTC-PERP:USDT for the perpetual — and the destination venue travels on the order in ExDestination (100).

An Axon exchange link carries its own lifecycle: the link reports CONNECTED before it is ready to trade, and open orders, trading history and positions are synchronized — the documented extended statuses run from Sync open orders through Ready to Trade — before trading is enabled on it. Connectivity state per venue is pushed to the client as TradingSessionStatus (35=h) rather than polled. Axon also reserves a 10-minute daily maintenance window per datacenter.

A desk still works inside each venue's own trading rules, and a normalization layer does not change what a venue allows. Which of Bybit's rules reach a given client depends on how that client's orders arrive at Bybit: Axon's venue-side route is a per-venue fact, and the documentation notes that a venue may expose several routes, WebSocket and FIX among them, as separate routing destinations.

FAQ

Does Bybit have a FIX API?
Yes. Bybit launched a FIX 4.4 API for spot trading on 1 September 2026, reachable at fix-oe.bybit.com on port 9000 over TLS.

Which products does Bybit FIX cover, and what is in its published scope?
The order messages require Category tag 30010 and the documented value is spot, and the launch scope published by Bybit covers new order, amend and cancel.

How do I get access to Bybit FIX API?
Access requires whitelist onboarding at UID or institutional ID granularity, requested through a Bybit relationship manager, and an API key that is self-generated RSA with FIX API enabled.

Does Bybit FIX support resend requests?
No. ResendRequest tag 35=2 and SequenceReset tag 35=4 are not implemented, sequence numbers restart from 1 on every connection, and messages unconsumed at disconnect are not retransmitted.

How do I amend an order on Bybit FIX?
Through AtomicReplaceRequest, message type XAR. The standard OrderCancelReplaceRequest, message type G, is not supported.

Does the FIX API have its own rate limits?
No. The FIX API draws on the same rate limit pool as REST V5, and remaining weight is reported in tags 30007, 30008 and 30009.

Sources

• Bybit, FIX API Integration Guide — https://bybit-exchange.github.io/docs/fix-api/guide
• Bybit, Place Order — https://bybit-exchange.github.io/docs/fix-api/create-order
• Bybit, Amend Order — https://bybit-exchange.github.io/docs/fix-api/amend-order
• Bybit, Cancel Order — https://bybit-exchange.github.io/docs/fix-api/cancel-order
• Bybit, Execution Report — https://bybit-exchange.github.io/docs/fix-api/execution-report
• Bybit, Set Disconnect Cancel All — https://bybit-exchange.github.io/docs/v5/order/dcp
• Bybit, V5 Changelog — https://bybit-exchange.github.io/docs/changelog/v5
• Bybit API Announcements, New Feature — FIX API for Spot Trading
• Axon Trade, FIX and REST API documentation — https://docs.axon.trade/

Facts verified as of October 2026. Protocol behaviour is stable, but endpoints, limits and scope should be re-checked against the live documentation before reuse.