Deribit FIX API Overview

TL;DR

Deribit runs a first-party FIX API built as a subset of FIX 4.4, with some tags borrowed from FIX 5.0 and a set of custom Deribit tags.

The thing that catches integrators out is not in the message tables. Most Deribit spot instruments are no longer matched by Deribit at all — they are routed to Coinbase Exchange, where order entry accepts a narrower set of tag values and the public trade tape is not served. Over FIX there is no flag that tells you which instrument is which.

Deribit FIX at a glance

Verified October 2026. Endpoints and limits change more often than the behaviour described below, so re-check them against live docs before building.

The public FIX endpoint moved. Deribit states that the FIX endpoint is no longer reachable over the internet via www.deribit.com and that clients should use fix.deribit.com for production and fix-test.deribit.com for test. Any integration or article still pointing at the old host describes a path that no longer answers.

Where your spot order is actually matched

Deribit spot instruments are matched in one of two places. A small number continue to be matched on the Deribit matching engine, the same engine that matches derivatives. Most are routed to Coinbase Exchange, where Deribit sends the order for matching.

Both kinds trade through the same Deribit APIs, with the same authentication, the same sessions and the same instrument names, and both return the same order and trade objects. Derivatives are never affected, including derivatives quoted in the same currencies as a routed spot pair.

The difference is narrow and specific: a routed instrument accepts a smaller set of order parameters, and it serves no public trade tape.

Why your FIX session cannot tell you which is which

This is the constraint that shapes the integration, not a detail to note and move past.

Over JSON-RPC, routed instruments are identifiable: public/get_instrument and public/get_instruments return is_cbe_routed: true and its alias is_csr: true. Both fields are omitted entirely for spot matched on Deribit and for every other instrument, so a client tests for presence rather than for a false value.

Over FIX there is no routing flag in the reference data. Security List (y) returns both kinds as ordinary FXSPOT entries, and Deribit directs clients to identify routed instruments through the JSON-RPC methods instead.

Two spot instruments look identical in Security List. One is matched on the Deribit engine, the other on Coinbase Exchange, and only the JSON-RPC instrument methods say which is which.

The consequence for a FIX-only integration is direct. Two instruments that look identical in Security List will reject different orders, and one of them will never deliver a trade entry on the market data session. A desk that wants to know which is which has to call a JSON-RPC method, which means the reference-data path and the trading path no longer run over the same protocol. Deribit also notes that which pairs are routed is a configuration decision that can change, so the answer cannot be cached as a static list.

What routing changes, tag by tag

Three more differences do not fit in a table row.

Post-only inverts. On the Deribit matching engine, a post-only order that would match on arrival has its price adjusted by one tick into the spread, unless the reject flag is set, in which case it is rejected instead. On a routed instrument the price is never adjusted, which is why the reject flag is mandatory there: post-only without it is rejected with post_only_not_allowed (11055).

Fills are asynchronous. On a routed instrument the first Execution Report acknowledges that Coinbase accepted the order, and does not necessarily carry any fills. Execution is followed through subsequent Execution Reports on the session.

The trade tape is absent, the book is not. Deribit only observes a match on Coinbase when one of your orders was a party to it, so rather than publish partial data it rejects trade-derived requests. On FIX, MDEntryType (269) = 2 Trade is rejected in a Market Data Request and answered with a Market Data Request Reject (Y); Bid and Offer requested in the same message are still served. Market Data Snapshot (W) and Market Data Incremental Refresh (X) therefore never carry trade entries for routed instruments. Book data is unaffected, because Deribit receives the full Coinbase L2 book.

Your own fills are always complete on both venues, through Execution Reports and Trade Capture Report (AE).

Rejections specific to routed instruments arrive on FIX as an Execution Report (8) with OrdStatus (39) = 8, with the reason in Text (58) and the full code list on the routed-spot page. One of them is worth knowing before you write the handler: 11060 not_supported_for_coinbase_routed_spot also appears under its legacy message not_supported_for_csr_spot, so a handler keyed to one spelling will not catch the other.

Order types do not mean what their FIX names mean

A FIX engine that maps OrdType (40) by the names in the 4.4 specification will build the wrong orders on Deribit. The values and their Deribit meanings:

Two of those are the trap. Value J, whose FIX name is Market If Touched, is Deribit's stop limit. Value S, whose FIX name is Stop Limit on Bid or Offer, is Deribit's stop market. The order type a desk intends is resolved from the combination of OrdType and the presence of StopPx, not from the enum name alone.

Trailing stops need PegPriceType (1094) = 8, Trailing Stop Peg, with the offset in PegOffsetValue (211).

Algo orders require the trigger method in DeribitConditionTriggerMethod (5127), which selects mark price, trade or index.

The same value is also labelled differently in different places. New Order Single gives OrdType value 4 as stop limit, annotated trailing stop; the routed-spot page gives the same value as plain Stop Limit when listing the three types a routed instrument accepts. The two pages are describing different things — one the meaning of the value, the other which values are accepted — so a mapping table built by copying labels from whichever page was read first will carry the wrong name for the same number.

How order size is expressed

Quantity on Deribit is in contracts by default, not in coins. QtyType (854) selects the unit: 0 Units or 1 Contracts, with Contracts the default.

When QtyType is Units, the meaning of OrderQty (38) changes per instrument class: USD for perpetual and inverse futures, the underlying base currency coin for linear futures, and the amount of the corresponding cryptocurrency for options. The server converts Units into Contracts when the order is placed.

The conversion is one-way as far as the session is concerned. In the Execution Report, QtyType is documented as currently only 1, Contracts, and OrderQty, CumQty and LeavesQty are all stated in contract units corresponding to the ContractMultiplier in Security List. A desk that submits in Units and reconciles on the response has to apply the multiplier itself.

Deribit later added a second signal for the same problem. Execution Reports carry an optional CashOrderQty (152) to distinguish value-based orders from quantity-based ones: on BTC and ETH inverse futures and perpetuals, where size is specified as a USD amount, both OrderQty (38) and CashOrderQty (152) are present and equal, and on quantity-based orders CashOrderQty is absent.

One more field behaves unlike its name. Commission (12) on the Execution Report is documented as deprecated and always 0. Fee information is not read from that tag.

Two order forms that apply only to options

Two order forms on the Deribit FIX API apply to options and to nothing else on the venue. DeribitAdvOrderType (100012) marks an advanced options order: value 0 is an implied volatility order, where the price defines a fixed implied volatility in percent, and value 1 is a USD order, where the price defines a fixed USD price of the option. Advanced USD orders are not supported for linear options.

The corresponding values come back on the Execution Report in Volatility (1188) for implied volatility orders and PeggedPrice (839) for USD orders.

FIX 4.4 has no price field that holds a volatility figure. That is why the feature arrives as a custom tag plus Volatility (1188), and not as another OrdType value.

The market-maker surface

The session carries mass quoting and Market Maker Protection alongside ordinary order entry. Two facts about them change plans rather than code. MMP is not self-service: DeribitMMProtection (9008) is an order-level flag, but activating Market Maker Protection on an account requires manual admin action. And neither mass quotes nor MMP are available on spot — both are derivatives-only.

Session mechanics worth knowing before the first logon

Logon (A) must be the first message the client sends. On success the exchange echoes it back; on failure it answers with a Logout (5) carrying a reason and closes the connection.

Authentication is a hash rather than a signature over header fields: RawData (96) carries a strictly increasing timestamp and a nonce, and Password (554) is the base64-encoded SHA256 hash of that content concatenated with the client secret. Exact encodings and byte ranges are on the logon page.

Several logon tags change the shape of the session rather than its security, and each solves a problem that otherwise shows up in production:

• CancelOnDisconnect (9001) enables or disables session-level cancel on disconnect, defaulting to the account setting when the tag is absent. The opposite default applies on some venues — Kraken enables it on every FIX trading session.
• UseWordsafeTags (9002) moves Deribit custom tags from the 100000 range down to the 5000 range, for FIX engines that cannot handle the extended tag range. Deribit gives Volume24h (100087) becoming 5078 as the example, and the setting applies for the rest of the connection.
• DeribitSequential (9007) pushes all messages, including order changes and notifications, through a single queue, removing the distinction between the request-response queue and the notification queue. Deribit notes this may deliver call-return information more slowly than the two-queue default.
• UnsubscribeExecutionReports (9009) stops notification Execution Reports entirely, leaving only responses to this connection's own order operations.
• ConnectionOnlyExecutionReports (9010) narrows notifications to orders created on this connection, so Execution Reports can be split across several connections to the same subaccount.
• ReportFillsAsExecReports (9015) removes the FillsGrp group from the Execution Report and reports fills as separate Execution Reports with ExecType = F.

ReportFillsAsExecReports (9015) is the one to decide early, because it changes the shape of the data rather than its routing. By default the FillsGrp group carries fills inside the report, with FillExecID (1363) formed as the instrument and a trade sequence number joined by a hash, for example BTC-28SEP18#38, and FillLiquidityInd (1443) marking added or removed liquidity. Turning on 9015 changes the shape of every fill a reconciliation path sees.

Cancel on disconnect can also be overridden at the end of a session: DontCancelOnDisconnect (9003) on the Logout disables cancel on disconnect for that connection even if it was enabled at logon or in account settings.

That override exists because cancel on disconnect is not limited to abnormal disconnects. Deribit states that if CancelOnDisconnect (9001) was set at Logon, all orders are cancelled at Logout — including the clean, expected logout that a deployment or a nightly restart performs. A desk that intends its resting orders to survive a planned shutdown sets 9003 on the way out.

What changed recently, and what it breaks

The reference pages describe the current state. The changelog is where the breakage lives.

• RFQ over FIX was removed. Quote Request (R), Quote Request Reject (AG), Quote Status Report (AI) and RFQ Request (AH) were deleted in the release of 7 October 2025, having been added in March 2022. Any integration or guide written against the older message set is describing messages that no longer exist.
• Iceberg orders cannot be fully hidden. MaxShow (210) was replaced by DisplayQty (1138) on 10 June 2025, and DisplayQty = 0 now means no hidden volume, that is the full quantity is displayed. Omitting the field gives the same result. The old behaviour, where a client could hide the entire quantity, is gone.
• Order entry on routed spot was constrained. The release of 18 August 2026 restricted OrdType, TimeInForce, ExecInst, DisplayQty and the trigger method on spot instruments routed to Coinbase, and rejected MDEntryType = 2 for them in market data requests.
• Security List gained UnderlyingSecurityType (310) for all instruments, with values CRYPTO, COMMODITY and EQUITY.
• Two smaller changes worth grepping your codebase for. Non-printable ASCII in string values now produces a decoding error, and Order Mass Status Request gained MassStatusReqType (585) value 10 for the history of partially or fully filled orders.

Two documentation versions, and custom tags from three ranges

Deribit publishes the FIX documentation in two versions, production and upcoming, with identical message catalogues, so any difference sits inside individual message definitions rather than in what the API offers — a team migrating diffs the messages it actually uses, not the overviews.

Separately, custom tag numbers are not drawn from one range. The New Order Single table lists DeribitLabel as 100010 and DeribitAdvOrderType as 100012 in the extended range, DeribitMMProtection as 9008, and DeribitConditionTriggerMethod as 5127 — three different ranges in a single message definition. A dictionary built by assuming Deribit custom tags share a prefix will not match the documentation.

Deribit has a second FIX surface, and it is not FIX 4.4

Everything above describes the FIX API reached at fix.deribit.com. It is not the only FIX at Deribit.

Starbase is Deribit's high-performance matching engine for institutional trading and market makers, with order entry over a Simple Binary Encoding API rather than FIX. Its reporting path is FIX: a FIX Drop Copy feed on FIX 5.0 SP2 over a FIXT.1.1 session layer. A desk running both implements two FIX dialects against one venue, and they diverge at the first field of the first message — a logon carrying an older BeginString such as FIX.4.4 is rejected before parsing can identify the sender, so no reject message comes back at all.

Three facts decide whether any of this concerns you. Starbase is reachable only through hosted colocation or a cross-connect in Equinix LD4 in London, or through AWS Private Link, with no public internet path. Spot order books are not available on it. And order state does not cross over: trades and positions from Starbase orders reach the standard WebSocket API, but the classic JSON-RPC open-order methods and private order subscriptions do not return open Starbase orders or their lifecycle updates.

The two halves of this article meet there: the same spot business that leaves the Deribit matching engine for Coinbase is the business Starbase does not take. Nothing else is moving — Deribit states that the standard WebSocket API is supported indefinitely and that regular order entry is unaffected.

FAQ

Does Deribit have a FIX API and what version is it
Yes. Deribit operates a first-party FIX API built as a subset of FIX 4.4 that also includes some FIX 5.0 tags and several custom Deribit tags.

How do I connect to the Deribit FIX API
Production is fix.deribit.com on port 9881 for raw tcp and 9883 for ssl, and the test environment is fix-test.deribit.com on the same two ports. Deribit has retired access to the FIX endpoint through www.deribit.com.

Are Deribit spot orders matched on Deribit
Some are and most are not. Most spot instruments are routed to Coinbase Exchange for matching, while a small number continue to be matched on the Deribit engine. Derivatives are never routed.

How do I tell whether a Deribit spot instrument is routed to Coinbase
Not over FIX. Security List returns both kinds as ordinary FXSPOT entries, so the routing flag has to be read from the JSON-RPC methods public slash get_instrument or public slash get_instruments, which return is_cbe_routed true for routed instruments.

Why does my Deribit market data request return no trades
On a spot instrument routed to Coinbase, MDEntryType 269 equals 2 for trades is rejected, so snapshots and incremental refreshes never carry trade entries for it. Bid and offer are still served, fed from the full Coinbase book.

Why was my post only order rejected on Deribit spot
On a routed instrument post only is accepted only with the reject flag, ExecInst 18 equals 6A. A bare 6 is rejected with post_only_not_allowed, because the price of a routed post only order is never adjusted into the spread.

Does Deribit FIX still support RFQ
No. The RFQ messages were removed in the release of 7 October 2025.

In what units is a Deribit FIX order quantity expressed
In contracts by default. QtyType 854 can be set to Units, in which case the quantity is in USD for perpetual and inverse futures, in the base currency coin for linear futures, and in the amount of cryptocurrency for options, and the server converts it to contracts when the order is placed.

Does Deribit use more than one FIX version
Yes. The main Deribit FIX API is a subset of FIX 4.4, while the Starbase FIX Drop Copy feed runs on FIX 5.0 SP2. They are separate paths with separate credentials. Order entry on Starbase runs over a binary SBE protocol rather than FIX, while FIX on Starbase is the drop copy feed.

Can I place an options order in implied volatility terms on Deribit FIX
Yes. DeribitAdvOrderType 100012 set to 0 marks an implied volatility order where the price defines a fixed implied volatility in percent, and set to 1 marks a USD order, which is not supported for linear options.

Where Axon Trade fits

Axon Trade builds trading infrastructure for institutional and professional traders: FIX API connectivity, real-time market data and order execution. Everything above is one venue's dialect. Absorbing it, so that it never reaches the client's trading system, is what the layer does.

The client side is a single, slightly modified FIX 4.4 session reaching 30+ exchanges, with a canonical slash symbology such as ETH slash USDT identical for market data and execution across all of them. One trading session is the entry point for all of an organization's accounts and exchanges, so adding a venue is a configuration change rather than a new dialect and a new parser. Administrative work — creating accounts, managing exchange keys, extracting trading history, configuring access to trading and FIX sessions — runs over a separate REST API rather than through the trading path.

On Deribit specifically. Axon connects through two session types, trading and market data. On the venue leg, market data and the instrument list are taken from Deribit over Deribit's own FIX.

Normalized symbols carry the venue's instrument underneath: Deribit's BTC-PERPETUAL is PERP:BTC-PERP:BTC on the Axon side, ETH-PERPETUAL is PERP:ETH-PERP:ETH, and BTC_USDC-PERPETUAL is PERP:BTC-PERP:USDC. Reference data arrives through SecurityList (35=y) in the same shape on every venue, and one MarketDataRequest (35=V) subscribes across multiple symbols and multiple exchanges at once.

Coverage on Deribit is perpetuals, dated futures and spot, with market and limit order types. Options are not covered; a desk trading Deribit options reaches them through Deribit directly.

The same venue by venue reading is published for Kraken, Coinbase Exchange and Binance Spot.

What a normalization layer does not change is the venue itself. Deribit decides where a spot instrument is matched, which tag values that instrument will accept and whether its trade tape exists at all, and a desk still has to know those facts whichever route it takes. What the layer gives back is that the reading happens once per venue, instead of an integration being rebuilt around each one.

Sources

Facts verified as of October 2026 against Deribit's official API documentation. Specific strings, endpoints and limits change; re-check against live docs before reuse.

• Deribit Production FIX API Overview — docs.deribit.com/fix-api/production/overview
• Deribit Upcoming FIX API Overview — docs.deribit.com/fix-api/upcoming/overview
• Deribit FIX API Changelog — docs.deribit.com/changelogs/fix
• Spot Trading, Deribit and Coinbase-Routed Instruments — docs.deribit.com/articles/spot-trading-venues
• Logon (A), Production FIX API — docs.deribit.com/fix-api/production/logon
• Logout (5), Production FIX API — docs.deribit.com/fix-api/production/logout
• New Order Single (D), Production FIX API — docs.deribit.com/fix-api/production/new-order-single
• Security List (y), Production FIX API — docs.deribit.com/fix-api/production/security-list
• Starbase API Overview — docs.deribit.com/starbase/overview
• Starbase Connectivity Quickstart — docs.deribit.com/starbase/quickstart
• Starbase FIX Drop Copy API — docs.deribit.com/starbase/fix-drop-copy-api
• FIX 4.4 specification — fixtrading.org