Kraken FIX API Overview

TL;DR

Kraken operates a FIX 4.4 API for institutional and HFT clients, covering both Spot and Derivatives through a single Spot FIX API Key. Access comes through an Account Manager rather than self-service, and your IP addresses must be allow-listed before first logon.

It carries reference data, market data at both L2 and L3, order entry, order status and trading session status. It does not carry account data, so balances, history and funding stay on REST. The reason to choose it over Kraken's WebSocket is sequencing: FIX sessions are sticky, and a NEW and a CANCEL sent from the same session are guaranteed to reach the trading engine in order.

The two markets are less alike than "unified" suggests, and five points in Kraken's own documentation are inconsistent — the production hostname, whether unified means one session or two, whether you need one API key or two, whether Derivatives supports order amends, and how Cancel on Disconnect is configured. Each is covered in place below, with both sides cited.

What Kraken FIX is, and who it is for

Kraken's FIX implementation is based on FIX 4.4 and is aimed at institutional and HFT clients. Kraken describes it as the lowest-latency order entry path on the platform, with deterministic message sequencing, cancel-on-disconnect and session-based message replay.

The practical reason to choose it over Kraken's other protocols is ordering. FIX sessions use sticky routing: HAProxy assigns the gateway with the fewest active connections at logon, stickiness then applies at the SenderCompID level so every message from that session follows the same path of FIX Gateway to OES to Trading Engine, and NEW and CANCEL from the same session are guaranteed to reach the Trading Engine in order. WebSocket, by contrast, is load-balanced, and two sequential messages may take different paths to the engine's inbound queue.

If your strategy depends on a cancel arriving after the order it cancels, that guarantee is the difference between the two protocols. If it does not, WebSocket will be simpler to operate.

Getting access and connecting

Access is not self-service: Kraken directs prospective users to their Account Manager, and provides the designated CompIDs, hostname and ports during onboarding.

Before first logon:

• IP allow-listing — incoming addresses must be whitelisted.
• Transport — TCP SSL with TLS 1.3.
• DNS — records carry a five-minute TTL and are described as ephemeral. Resolve at connection time; do not bind to static IPs.
• UAT — a sandboxed acceptance environment covering the whole Kraken trading stack is available for certification before going live.

Which hostname do you actually connect to?

Three forms appear across Kraken's own pages for the production endpoint:

The two colo-london forms differ from each other only in one segment — vip-fix against vip-ws — and that is the sharpest of the three disagreements, because both describe the colocated path. The L3 guide ties the vip-ws form specifically to direct colocation and Beeks connectivity. Kraken does not state anywhere which hostname form corresponds to which connectivity tier, and the colocation guide does not mention hostnames at all.

The UAT hostnames split along the same lines: fix.uat.kraken.com in the introduction guide, colo-london.vip-fix.uat.kraken.com in the Unified FIX reference.

Use the hostname your Account Manager issues. Kraken states that it provides it during onboarding, which makes it authoritative over any docs page.

Colocation itself is gated: Kraken's core trading infrastructure for both engines sits at Equinix in London, and direct colocation requires VIP status, an executed NDA and an Equinix London presence.

Port allocation

Ports are the one part of connectivity where every page agrees.

WebSocket and REST share TCP 443.

What the API can do

Kraken's supported-message set groups into five capabilities, all available on both Spot and Derivatives:

The gap worth planning around is the sixth capability that does not exist: FIX carries no account data. Kraken's protocol comparison leaves the account-data row empty for Unified FIX on both markets and states that there are no account data endpoints, so balances, history and funding stay on REST.

Brokers have a dedicated path that is easy to confuse with sub-accounts. Tags 78 and 79 form Kraken's FIX broker allocation model, letting a prime broker allocate orders to client accounts within a single FIX session instead of opening one session per client. Kraken states explicitly that this is distinct from its sub-account feature, and it is enabled through an Account Manager.

Market data: L2 and L3

Kraken exposes two book depths over FIX, on separate ports.

The difference that matters for reconciliation: the L3 feed carries OrderID (Tag 278 / MDEntryID), so fills reported in ExecutionReports can be matched deterministically against book entries. Kraken states this is not possible with L2 data.

L3 depth can be requested as full book, 10, 100 or 1000 levels. The feed shows only orders resting in the visible book, and therefore excludes in-flight orders, unmatched market orders, untriggered stop-loss and take-profit orders, and the hidden quantity of iceberg orders.

L3 is not strictly better. Kraken notes its payload is larger because it describes every order rather than cumulative quantity per level, its checksum takes longer to compute because it also verifies order sequence within a price level, and it runs on a different market data stack — an authenticated channel rather than a public one.

Order types and the order lifecycle

Kraken handles all order types at the Trading Engine level.

Synthetic order types such as TWAP are not yet available over FIX; Kraken describes them as moving to a future Algo Engine.

Orders move through pending to open, then to partially_filled, filled, canceled or expired. On FIX, state is observed through ExecutionReport (MsgType=8), principally via OrdStatus (Tag 39), ExecType (Tag 150), CumQty (Tag 14) and LeavesQty (Tag 151), with Text (Tag 58) carrying the human-readable reason on rejection or cancellation.

Amends and queue priority. What you change decides whether you keep your place in the queue: reducing quantity only preserves time priority, while increasing quantity or changing price sends the order to the back of the queue at that price. For a market-making strategy this is the difference between an amend and a cancel-replace.

Orders pass three validation layers before reaching the book — the FIX Gateway checks message format and session authentication, the Order Entry Service checks account, instrument and geo-restrictions, and the Trading Engine checks balances, self-trade prevention and order limits. Configurable client-side risk controls such as fat-finger limits and max notional per order are not currently offered, so pre-trade notional caps belong in your own stack.

What differs between Spot and Derivatives

No single Kraken page collects this in one place, and it is where "unified" stops meaning "identical".

Underneath, the two markets run on separate trading engines, and each FIX trading session connects to the engine for the instrument being traded.

Amend on Derivatives is where Kraken contradicts itself. The FIX Introduction guide's supported-messages table marks OrderCancelReplaceRequest (Tag 35=G) as coming soon for Derivatives. The protocol comparison guide's Derivatives table lists order amend over Unified FIX as available, naming the same MsgType=G. Both are current Kraken documentation. If your Derivatives strategy depends on in-place amends rather than cancel-replace, confirm with your Account Manager rather than designing around either page.

Symbols differ between Kraken's own protocols

The same instrument carries different identifiers depending on which protocol you ask. For Bitcoin against USD, FIX uses XBT/USD, WebSocket uses BTC/USD, and REST accepts XXBTZUSD or XBT/USD. Derivatives instruments follow their own convention, with the BTC perpetual identified as PI_XBTUSD across REST, WebSocket and FIX alike.

An integration built against one Kraken protocol and extended to another has to translate between these forms rather than reuse the string.

Does "unified" mean one session or two?

Kraken markets the API as Unified FIX, and several pages describe it as covering both markets in one session. The protocol comparison guide says the API covers both Spot and Derivatives in a single session, and repeats the point in its combined-markets tab. The documentation index says the same.

Everything else describes two separate sessions: Spot Trading and Derivatives Trading sit on different ports, 4001 and 4003; Derivatives sessions use a SenderCompID with a DRV suffix; the two markets run on separate trading engines; and the Unified FIX reference itself uses the plural, saying the key authorises both Spot and Derivatives sessions on the appropriate ports.

Read together, "unified" describes the credential set rather than the transport: one FIX API key covers both markets, but a desk trading both establishes a session per market, on its own port, with its own CompID. A team that provisions one connection on the strength of the "single session" wording will find the second market unreachable on it.

Do you need one API key or two?

Kraken's answer depends on which page you read.

The Unified FIX reference is unambiguous that one credential is enough: authentication uses a Spot FIX API key, and the same key authorises both Spot and Derivatives sessions on the appropriate ports, with no separate Derivatives FIX credentials required.

The Authentication guide sets out a two-key arrangement. It pairs Spot trading with a FIX key created under your Spot account and Derivatives trading with a key created under your Derivatives account, notes that a FIX key is always created as a Spot key even when used for Derivatives, and recommends separate keys for the two markets even though the authentication mechanism is identical.

These may be reconcilable — one key sufficient, two recommended — but Kraken does not state that anywhere, so treat it as a reading rather than guidance. Confirm the arrangement with your Account Manager before building around either page.

Logon

Market Data sessions authenticate with the SenderCompID alone; Trading sessions require an additional HMAC signature. Kraken documents the trading logon signature as six steps:

1. Generate a Nonce — current time in milliseconds since the Unix epoch.
2. Build the MessageInput string from fixed FIX fields.
3. Compute SHA256(MessageInput + Nonce).
4. Sign that with HMAC-SHA512 using your base64-decoded API Secret.
5. Base64-encode the result — this is your Password (Tag 554).
6. Send the Logon with UserName (Tag 553), Password (Tag 554) and Nonce (Tag 5025).

Trading and Market Data sessions share the same SenderCompID and differ by port.

Operating it

Cancels are scoped to the session that placed the order

An OrderCancelRequest can only cancel orders placed on that same FIX session. The exception is OrderMassCancelRequest (Tag 35=q), which cancels all orders on the account regardless of origin, and WebSocket and REST can cancel from any source.

The consequence for failover design: a second FIX session taking over from a dead one cannot cancel the dead session's working orders one by one. It has to reach for mass cancel, or for REST or WebSocket.

Cancel on Disconnect, and a documentation conflict

CoD is enabled by default on every FIX trading session, and all open orders placed on the session are cancelled automatically when the connection drops.

How it is configured is stated two different ways. The FIX Introduction guide says it is set per session via CancelOrdersOnDisconnect (Tag 8674) on the Logon message, with no onboarding step required. The Order lifecycle guide says CoD is configured at the session level during onboarding. If you expect to toggle CoD per session at logon, confirm it is not pinned at provisioning.

A protocol-independent safety net exists alongside it: CancelAllOrdersAfter sets a countdown that cancels all open orders if not refreshed before expiry.

Rate limits are asymmetric

• Derivatives — limits are at the session level, each FIX session with its own token bucket.
• Spot — FIX shares a unified account-level bucket with WebSocket and REST.

So on Spot a busy REST reconciliation loop and a FIX order flow draw on the same budget, while on Derivatives an additional session brings additional capacity. Hitting a limit returns a business-level reject.

Separately, an error-rate safeguard disconnects rather than rejects: too many errors per second and the session is dropped, with the threshold raisable through an Account Manager. Neither the FIX introduction nor the rate limits guide states the numeric threshold — the rate limits guide covers the trading rate counter, which is a different mechanism.

Daily rollover at 22:00 UTC

Sessions run 24/7 with a logical rollover every day at 22:00 UTC lasting roughly 30 seconds, after which Trading and Market Data sequence numbers reset to zero.

A FIX engine that treats a sequence reset as an error rather than an expected daily event will alert, or attempt a resend, once a day at a predictable time.

Replay follows standard FIX semantics: reconnecting with a lower-than-expected sequence number causes the gateway to replay ExecutionReports from that number, using FIX 4.4 gap-fill and resend semantics, with PossDupFlag (Tag 43) set to Y marking a possible duplicate.

ExecIDs do not round-trip UUIDs

Each ClOrdID (Tag 11) must be unique within a trading session, and Kraken recommends UUIDs or incrementing sequence numbers with a session prefix. But ExecID (Tag 17) is derived from ClOrdID at the gateway and base32 encoded, and if the ClOrdID is a UUID only the last 12 hex characters are recoverable from it.

Kraken recommends UUIDs in one rule and documents their truncation in the other. If reconciliation reads the identifier out of ExecID rather than ClOrdID directly, a UUID scheme gives back twelve hex characters and nothing more.

Connection reference

Verified against Kraken documentation in October 2026. Hostnames, ports and session timings change more often than the behaviour described above, so re-check them against the live docs before relying on them.

Protocol: FIX 4.4, Spot and Derivatives.

Production hostname: inconsistent across Kraken sources — fix.kraken.com, colo-london.vip-fix.kraken.com, colo-london.vip-ws.kraken.com. Use the hostname issued at onboarding.

Ports: 4000 Spot MD L2, 4001 Spot Trading, 4002 Derivatives MD L2, 4003 Derivatives Trading, 4004 Derivatives MD L3, 4005 Spot MD L3.

Rollover: daily at 22:00 UTC, approximately 30 seconds, sequence numbers reset to zero.

Transport: TCP SSL, TLS 1.3, DNS TTL five minutes.

FAQ

Does Kraken support FIX?
Yes. Kraken operates a FIX 4.4 API covering both Spot and Derivatives markets, aimed at institutional and HFT clients, with access arranged through an Account Manager.

What FIX version does Kraken use?
FIX 4.4. Every Kraken documentation page covering the API states 4.4, for both Spot and Derivatives.

What can the Kraken FIX API do?
Reference data, market data at L2 and L3, order entry, order status and trading session status, on both Spot and Derivatives. It carries no account data, so balances, history and funding stay on REST.

Does Kraken FIX provide L3 order book data?
Yes, on port 4005 for Spot. The L3 feed carries order IDs, which lets fills in ExecutionReports be matched deterministically against book entries. Kraken states that is not possible with L2 data.

Does Kraken Unified FIX use one session for Spot and Derivatives?
Kraken describes it that way on some pages, but the rest of the documentation points to one session per market. Spot Trading and Derivatives Trading use different ports, Derivatives sessions carry a DRV suffix on the SenderCompID, and the two markets run on separate trading engines. Unified best describes the credential set rather than the transport.

Do I need separate credentials for Kraken Spot and Derivatives FIX?
The Unified FIX reference says one Spot FIX API Key authorises both. The Authentication guide recommends separate keys for Spot and Derivatives. Derivatives sessions use a SenderCompID with a DRV suffix in either case.

Can I cancel a Kraken order on a different FIX session than the one that placed it?
Not with a single order cancel. OrderCancelRequest only affects orders placed on the same FIX session. OrderMassCancelRequest, tag 35 equals q, cancels everything on the account regardless of origin, and REST or WebSocket can cancel from any source.

Does Kraken FIX support order amends?
On Spot yes, via OrderCancelReplaceRequest, tag 35 equals G. On Derivatives the Kraken documentation is inconsistent. The FIX introduction marks amend as coming soon, while the protocol comparison guide lists it as available over Unified FIX. Confirm with your Account Manager.

Does amending an order on Kraken lose queue priority?
Reducing quantity only preserves time priority. Increasing quantity or changing price moves the order to the back of the queue at that price.

Is Cancel on Disconnect available on Kraken FIX?
Yes, and it is enabled by default on every FIX trading session. Kraken documentation is inconsistent on configuration, describing it both as set per session on the Logon message via tag 8674 and as configured during onboarding.

Does Kraken FIX support TWAP or other algo orders?
Not yet. Synthetic order types are described as not currently available via FIX, with a future Algo Engine planned.

Where Axon Trade fits

Axon Trade provides advanced trading infrastructure for institutional and professional traders, offering high-performance FIX API connectivity, real-time market data, and smart order execution solutions. The problem it addresses is the one this article has just worked through at length: every venue carries its own dialect, its own symbol forms and its own documentation to reconcile, and a desk trading several of them does that work once per venue. A desk on Axon connects one slightly modified FIX 4.4 session and reaches supported venues through it, using a canonical slash-format symbol such as ETH/USDT that is identical for market data and execution across 30+ exchanges, rather than one form per venue and per protocol.

Kraken shows how the two layers sit. The FIX 4.4 session is the interface Axon presents to the client; on the venue leg, Axon reaches Kraken over WebSocket for both market data and order entry, and over REST for the symbol list. A desk that wants FIX semantics on Kraken therefore has two routes — Kraken's own FIX, documented above, or a normalized FIX session that covers Kraken alongside other venues.

On Kraken the Axon session covers spot, carrying new order, cancel, replace, order status and mass order status, with market, limit and stop order types; futures trading is not implemented, and self-trade prevention is configured by the client rather than by Axon. Mass cancel is not available on the Axon session, so a desk that wants an account-wide kill switch on Kraken reaches for the venue's own path.

What a normalization layer does not change is the venue itself: Kraken decides which instruments exist, how its engines treat an amend and when its sessions roll, and a desk still has to know those facts whichever route it takes. What the layer gives back is doing that reading once per venue instead of rebuilding an integration around each one.

Sources

• Kraken FIX Introduction guide — docs.kraken.com/exchange/guides/fix/introduction
• Kraken Unified FIX reference — docs.kraken.com/exchange/api-reference/unified-fix
• Kraken FIX Authentication guide — docs.kraken.com/exchange/guides/fix/authentication
• Kraken Choose your protocol guide — docs.kraken.com/exchange/guides/general/api-comparison
• Kraken Order lifecycle guide — docs.kraken.com/exchange/guides/general/order-lifecycle
• Kraken Spot Level 3 Market Data guide — docs.kraken.com/exchange/guides/general/l3-data
• Kraken Colocation and connectivity guide — docs.kraken.com/exchange/guides/general/colocation
• Kraken Spot Trading Limits guide — docs.kraken.com/exchange/guides/general/ratelimits
• Kraken Sub-accounts guide — docs.kraken.com/exchange/guides/general/subaccounts
• Kraken documentation index — docs.kraken.com/llms.txt
• FIX 4.4 protocol specification — FIX Trading Community, fixtrading.org/standards

Facts verified as of October 2026. Principles are stable, but specific strings, hostnames and port assignments should be re-checked against live Kraken documentation before reuse.