Skip to main content
Kraken’s Spot and Derivatives markets run on separate trading engines, each with its own endpoints and latency characteristics. The right protocol combination depends on which market you trade.
Spot offers three protocols. They share the same rate limit counter — choose based on your latency requirements and feature needs.
Best for: operational tasks that don’t require real-time streaming — checking balances, querying order history, managing deposits and withdrawals, Earn, sub-account transfers.Not recommended for: latency-sensitive order entry or real-time market data. Each request incurs a full HTTP round-trip.Base URL: https://api.kraken.com
Best for: institutional and HFT clients requiring the lowest latency, deterministic message sequencing, cancel-on-disconnect, and session-based message replay. Available for colocated deployments alongside WebSocket.Uses a Spot FIX API Key pre-configured with the correct permissions. Covers both Spot and Derivatives in a single session.Limitations: requires NDA and VIP status for production colocation. Cannot cancel orders from a different FIX session. No account data endpoints.

Rate limits

If you run parallel order management systems across multiple protocols on Spot, they share a single rate counter. A burst on one will affect capacity on the others.

Symbol formats

The same instrument has different identifiers across protocols:
WebSocket v2 and REST accept the more readable format (e.g. BTC/USD). FIX uses the same short format. REST also accepts the legacy Kraken format (e.g. XXBTZUSD) for backwards compatibility.

Cancel scope

This is a critical architectural consideration. If your FIX session disconnects and reconnects as a new session, you cannot cancel orders from the previous session using FIX OrderCancelRequest — you must use OrderMassCancelRequest or fall back to REST/WebSocket.

Sequencing guarantees

FIX (sticky routing): Each FIX session is bound to a specific FIX Gateway instance and follows a deterministic path to the trading engine. New orders and cancels from the same session arrive in order at the engine. WebSocket (non-sticky): Connections are load-balanced. Two messages sent on the same connection may follow different paths and arrive out of order at the engine’s inbound queue. REST: No ordering guarantees between separate HTTP requests. For strategies where the sequence of a cancel and a new order matters (e.g. cancel-replace at a specific price), FIX provides the strongest guarantee.

WebSocket v1 vs v2

v1 is maintained for existing integrations. All new integrations should use v2.

Quickstart

Set up your first API key and place your first order

Order lifecycle

How order states and transitions work across all protocols

Colocation and connectivity

Low-latency connectivity tiers — from cloud to cross-connect

WebSocket reconnection

Handle disconnects, re-subscription, and state reconciliation

Rate limits

How rate limits work across REST, WebSocket, and FIX

Error reference

Full list of error codes and how to handle them