Overview
Kraken is one of the longest-established and most regulated cryptocurrency exchanges, with a strong reputation for security, reliability, and institutional-grade infrastructure. Founded in 2011, Kraken has maintained a track record of operational continuity through multiple market cycles and has obtained regulatory licences in key jurisdictions — including being one of the first cryptocurrency exchanges to receive a special purpose depository institution (SPDI) charter in the United States. For trading systems and applications that prioritise exchange counterparty reliability and regulatory standing alongside execution quality, Kraken is a significant venue.
Kraken provides two API generations that are both in active use: the REST API v2 and WebSocket API v2 (the current generation introduced progressively from 2022 onwards), and the legacy REST API (v0/v1) and WebSocket API v1. The v2 APIs offer a cleaner, more consistent interface with improved authentication, better error handling, and expanded functionality for futures (through Kraken Futures, a separate product). Understanding which API version to target — and the differences between them — is an important integration decision.
Kraken's trading products cover spot trading across hundreds of cryptocurrency pairs, Kraken Pro for the advanced trading interface, and Kraken Futures (formerly Crypto Facilities) for perpetual and fixed-term futures contracts on major cryptocurrencies. The spot API and the Futures API are separate services with different endpoints, different authentication mechanisms, and different order models — an integration that covers both requires handling each distinctly.
We build Kraken integrations for algorithmic trading systems, portfolio tracking applications, multi-exchange execution infrastructure, and market data systems that need reliable connectivity to Kraken's spot and futures markets.
What Kraken Integration Covers
Kraken REST API v2 authentication. The current Kraken API uses a token-based authentication system for private endpoints.
API key generation: Kraken API keys are created in the account security settings with configurable permissions — Query Funds, Query Open Orders and Trades, Query Closed Orders and Trades, Create and Modify Orders, Cancel/Close Orders, Create and Modify Orders (Full Access), Export Funds. The permission model that restricts each key to the minimum capabilities required by the integration. The nonce window setting per key that configures how many simultaneous requests can be made with the key.
Message authentication code: Kraken's private REST endpoints require an authentication signature computed from the nonce, the API path, and the encoded request body. The signature computation: HMAC-SHA512 of the concatenation of the URI path and the SHA256 hash of the concatenation of the nonce and the URL-encoded POST data, using the base64-decoded API secret as the HMAC key. The API-Key header containing the API key and the API-Sign header containing the base64-encoded HMAC-SHA512 signature.
Nonce management: each API request includes a nonce parameter — an integer that must be strictly increasing for each request made with the same API key. The nonce management that generates strictly increasing nonce values, handles the nonce window within which multiple requests can share similar nonce values, and prevents nonce reuse that causes request rejection.
Spot trading REST API. The Kraken REST API for spot market order management.
Order placement: the POST /0/private/AddOrder endpoint for placing orders. Order types: market for immediate market execution, limit for price-specified limit orders, stop-loss for stop orders, take-profit for take-profit orders, stop-loss-limit for stop-limit orders, take-profit-limit for take-profit-limit orders, trailing-stop for trailing stop orders, trailing-stop-limit for trailing stop limit orders. The pair parameter for the trading pair (Kraken-format: XBTUSD, ETHUSD, or the ISO-format: BTC/USD), type for buy or sell, ordertype for the order type, price and price2 for price parameters, volume for the order quantity.
Order flags: the oflags parameter with comma-separated flags — post for post-only maker orders, fcib for prefer fee in base currency, fciq for prefer fee in quote currency, nompp for no market price protection, viqc for volume in quote currency.
Validation mode: the validate parameter that submits the order for validation without actually placing it — the test that confirms the order parameters are valid before committing real capital.
Order response: the txid array in the response containing the order transaction ID(s) — the Kraken order reference used for subsequent order queries and cancellations. The descr order description confirming the interpreted order parameters.
Order queries: the POST /0/private/QueryOrders endpoint for querying specific orders by transaction ID. The POST /0/private/OpenOrders endpoint for listing all open orders. The POST /0/private/ClosedOrders endpoint for order history with time range filtering.
Order cancellation: the POST /0/private/CancelOrder endpoint for cancelling a specific open order by transaction ID. The POST /0/private/CancelAllOrders endpoint for cancelling all open orders simultaneously. The POST /0/private/CancelAllOrdersAfter endpoint for the dead man's switch — scheduling automatic cancellation of all open orders after a defined number of seconds if not explicitly reset.
Batch order operations: the POST /0/private/AddOrderBatch endpoint for placing up to 15 orders in a single API call. The batch order placement that reduces API call count for strategies that place many simultaneous orders.
Balance and account data. Kraken account balance and trading information.
Account balance: the POST /0/private/Balance endpoint that returns the current balance for each asset in the account — the available balance for trading, before considering open orders. The balance breakdown by asset (XBT, ETH, USDT, USD, EUR, and other held assets).
Extended balance: the POST /0/private/BalanceEx endpoint that returns extended balance information including held balance (committed to open orders), credit used, and credit maximum for margin accounts.
Trade balance: the POST /0/private/TradeBalance endpoint for the trading account balance summary — the equivalent balance, the margin used, the unrealised PnL, and the cost basis.
Open positions: the POST /0/private/OpenPositions endpoint for margin trading positions — the position ID, the pair, the direction, the volume, the cost, the fees, the current value, and the unrealised PnL.
Trade history: the POST /0/private/TradesHistory endpoint for the history of executed trades with time range filtering and pagination via the ofs (offset) parameter.
Market data REST API. Public endpoints for market data and instrument specifications.
Asset pairs: the GET /0/public/AssetPairs endpoint that returns trading pair specifications — the pair name, the base and quote assets, the price decimal places, the lot decimal places, the minimum order volume, the fee schedule, the margin call level, the stop out level, and the trading pair status. The pair parameter for requesting specific pairs rather than all pairs.
Ticker: the GET /0/public/Ticker endpoint for current price data for one or more pairs — the bid price, ask price, last trade price, today's volume, today's VWAP, number of trades, 24-hour high and low, and opening price.
Order book: the GET /0/public/Depth endpoint for the current order book — the bid and ask price levels with volume and timestamp for each level. The count parameter for the number of levels to return (default 100, maximum 500).
Trades: the GET /0/public/Trades endpoint for recent trade history — the price, volume, time, direction (buy/sell), order type (market/limit), and miscellaneous information for each trade. The since parameter for retrieving trades after a specific trade ID for incremental data retrieval.
OHLC: the GET /0/public/OHLC endpoint for historical OHLCV bar data — the time, open, high, low, close, VWAP, volume, and count for each bar. Available intervals from 1 minute to 1 week.
WebSocket API v2. Real-time streaming market data and account updates via Kraken's WebSocket v2 interface.
Connection: the WebSocket v2 endpoint at wss://ws.kraken.com/v2 for public streams and authenticated private streams. The single endpoint for both market data and account data, with channel-based subscription distinguishing the data types.
Subscription format: the {"method":"subscribe","params":{"channel":"{channel}","symbol":["{pair}"]}} message for subscribing to market data channels. The {"method":"subscribe","params":{"channel":"{channel}","token":"{wsAuthToken}"}} format for authenticated private channels.
WebSocket authentication token: private WebSocket channels require an authentication token obtained from the POST /0/private/GetWebSocketsToken REST endpoint. The token that is valid for 15 minutes and must be included in private channel subscriptions. Token refresh before expiry for long-lived WebSocket connections.
Ticker channel: the ticker channel for real-time price updates — bid, ask, last price, daily high, low, volume, VWAP, and number of trades for each subscribed pair. The snapshot on subscription followed by updates on each price change.
Trade channel: the trade channel for individual trade events — the price, volume, direction (buy/sell), order type (market/limit), and timestamp for each executed trade. The tick data stream for real-time price discovery and trade-based indicator calculation.
Book channel: the book channel for order book updates — the snapshot of all bid and ask levels on subscription, followed by incremental updates (add, update, delete operations on individual price levels). The depth parameter for the number of book levels (10, 25, 100, 500, 1000). The checksum field that allows validating the local order book state against Kraken's checksum for detecting missed updates.
OHLC channel: the ohlc channel for real-time bar updates. The interval parameter for the bar timeframe — 1, 5, 15, 30, 60, 240, 1440, 10080, 21600 (minutes). The bar that updates on each new trade within the bar period and is finalised at bar close.
Executions channel: the authenticated executions channel for real-time order and trade events — new orders, order fills, partial fills, cancellations, and expiries. The real-time order status that the trading system uses for order tracking without polling the REST API. The fill data with execution price, volume, and fees.
Balances channel: the authenticated balances channel for real-time account balance updates — balance changes after each trade execution or deposit.
Kraken Futures API. The separate Futures API for perpetual and fixed-term futures contracts.
Futures authentication: the Kraken Futures API uses a different authentication mechanism from the spot API — HMAC-SHA512 of the concatenation of the post data and the SHA256 of the path with the nonce appended. The separate API key pair for Futures that is created in the Kraken Futures account settings.
Futures order placement: the POST /derivatives/api/v3/sendorder endpoint for placing futures orders. The orderType parameter — mkt for market orders, lmt for limit orders, stp for stop orders, take_profit for take-profit orders, ioc for immediate-or-cancel. The symbol for the futures contract (e.g., PI_XBTUSD for XBTUSD perpetual inverse, PF_XBTUSD for XBTUSD perpetual linear), side for buy or sell, size for the contract quantity.
Futures positions: the GET /derivatives/api/v3/openpositions endpoint for current open positions — the symbol, the side, the size, the entry price, the current price, and the unrealised PnL.
Futures account: the GET /derivatives/api/v3/accounts endpoint for the Futures account balances — the cash, the collateral value, the margin, and the unrealised PnL.
Futures WebSocket: the Futures WebSocket at wss://futures.kraken.com/ws/v1 with book, trade, and account event subscriptions for the futures products.
Rate Limit Management
Kraken enforces rate limits on both public and private REST API endpoints.
Public endpoint limits: public REST endpoints are limited by IP address — typically 1 request per second per IP for most endpoints, with burst capacity for occasional higher rates. The rate limit management that spaces public API calls to avoid triggering IP-based rate limiting.
Private endpoint rate limits: Kraken uses a counter-based rate limit system for private endpoints. Each account starts with a counter value (typically 15 or 20 depending on account tier), and each private API call decrements the counter. The counter refills at a rate of 1–2 per second depending on the account tier. When the counter reaches 0, requests are rejected. The counter-based rate limit management that tracks estimated counter state and paces private API calls to avoid depleting the counter.
Tier-based limits: Kraken's API rate limit allowance scales with the account's verification tier — Starter, Intermediate, Pro. Higher tier accounts have higher initial counter values and faster refill rates. The account tier configuration that determines the rate limit parameters for the integration.
Dead man's switch implementation. The POST /0/private/CancelAllOrdersAfter endpoint that provides an automated order cancellation safety mechanism — a countdown timer that cancels all open orders if not explicitly reset within the configured timeout.
Dead man's switch usage: the trading system that calls CancelAllOrdersAfter with a 60-second timeout at the start of each trading cycle, and resets the timer on each cycle. If the trading system loses connectivity or crashes, the 60-second timer expires and Kraken automatically cancels all open orders — preventing orders from being left open without the trading system monitoring them.
Technologies Used
- Rust — high-performance WebSocket stream processing, HMAC-SHA512 signature computation, order book state management, low-latency order placement
- Python — Kraken API integration for algorithmic strategy development and portfolio analysis using the
krakenexlibrary or direct HTTP implementation - C# / ASP.NET Core — Kraken integration for .NET-based trading platforms and portfolio management systems
- TypeScript / Node.js — Kraken integration for web-based trading tools and multi-exchange dashboards
- WebSocket — real-time market data and executions stream connectivity
- REST / HTTP — order management, account data, and historical market data
- HMAC-SHA512 — Kraken REST API request signing
- Redis — rate limit counter state, order state cache, WebSocket message distribution
- SQL (PostgreSQL / MySQL) — trade history, order records, position records, financial data
- Docker — containerised trading system deployment
- GitHub Actions — CI/CD pipeline for trading system deployment
Kraken's Position in Multi-Exchange Trading
Kraken's regulatory standing, long operating history, and institutional-grade infrastructure make it a trusted component of multi-exchange trading architectures for traders who diversify execution across venues for counterparty risk management or who need Kraken's specific market access (European EUR-denominated pairs, specific altcoins, futures through Kraken Futures).
In a multi-exchange architecture, the Kraken connector handles the Kraken-specific authentication (the nonce-based HMAC-SHA512 signature), the Kraken-specific pair naming conventions (XBTUSD versus BTC/USD versus BTCUSDT), the WebSocket v2 subscription model with its token-based authentication, and the Kraken Futures API's separate authentication and endpoint structure — insulating the strategy and portfolio management layers from these exchange-specific implementation details.
The order book normalisation that maps Kraken's order book format to the internal representation, the trade event normalisation that maps Kraken's execution events to the internal trade record format, and the balance normalisation that maps Kraken's asset names to the internal asset identifiers are the integration-level concerns that the Kraken connector handles to provide a consistent interface regardless of exchange-specific conventions.
Reliable Kraken Connectivity for Production Trading
Kraken integrations built to production standards — correct nonce management and HMAC-SHA512 signature computation, counter-based rate limit management that prevents counter depletion, WebSocket connection management with token refresh and reconnection, accurate order book maintenance with checksum validation, real-time execution tracking through the executions channel, dead man's switch for automated safety, and the operational monitoring that surfaces connectivity issues before they affect trading operations.