Public WebSockets API - common questions

Does Kraken have a WebSockets API? How can I connect to it?

Yes, Kraken has a WebSockets API. It is hosted at the following URLs:

Production environment:

Beta test environment:

See the documentation for more details. Note that the beta test feeds have a small built in delay, but that the production feeds are a real time stream.

No API key or authentication is required to connect to the public WebSockets API. All messages sent and received are encoded in the JSON format. For help with formatting your JSON correctly, you can find many suitable 'JSON formatters' across the web.

Do you have client code libraries available?

Yes, we do have an example client code library available. You can find a Python code example in this article and a full example code library from us on our GitHub.

What endpoints are supported?

A list of endpoints, including supported currency pairs, subscription types and additional parameters can been found in the documentation for the Public WebSockets API.

How do I know I'm successfully connected? How do I know I'm still connected?

When subscribed to a feed a '{u'event': u'heartbeat'}' will be received approximately every second. In between heartbeats trading data will be received, when and why trading data is received depends on the feed you are subscribed to.

If you are subscribing to the feed of a currency pair with low trading volume, you may only receive heartbeats for long periods.

If you unsubscribe to a feed you will no longer receive heartbeats or trading data and after being not subscribed to any feed for 1 minute you will be disconnected from the WebSockets feed.

When and why does the WS send my client data?

When and why trading data is received depends on the feed you are subscribed to. Please find an explanation for each subscription type below:

Ticker:  When there is a trade or batch of trades for a currency pair, a Ticker message is published for that pair. You will only receive this message if you are subscribed to the Ticker feed for this pair.

Trade:  Similarly, when there is a trade or batch of trades for a currency pair, a Trade message is also published for that pair. You will only receive this message if you are subscribed to the Trade feed for this pair.

OHLC: An updated OHLC interval is published for each interval when a trade or batch of trades for a currency pair is executed. You will only receive updates for the intervals that you are subscribed to.

If we cross an interval border, nothing is generated until the next trade.

Book: An initial snapshot of the Book with the chosen depth is published when first subscribed.

When new orders are added to the book or trades are executed that affect the book depth you are subscribed to, a message is published containing book updates for any affected price levels and volumes. These updates can contain only bids, only asks, or both. See How to build the “book”? below for details.

Spread: When a new ‘Best Ask’ or ‘Best Bid’ order is placed or a trade is executed that changes the ‘Best Ask’ or ‘Best Bid’ price, a message is published with the updated ‘Best Ask’ and ‘Best Bid’ price.

Do WebSockets feeds provide historical data or only current data?

The WebSockets only give current data, however it is possible to connect to the WebSockets for current data and the REST API for historical data simultaneously.

Use of the “reqid” parameter.

One parameter that many traders find helpful is the “reqid” parameter.

With the “reqid” parameter you can easily match the desired WS subscription with the “channelID” for that subscription. This will make it easier to match the trading data you receive with its currency pair, subscription type and any additional parameters.

Please be aware that if you make multiple WS subscriptions at the same time, they will all be assigned the same “reqid”. To assign a different “reqid” each feed must be subscribed to individually.

I want more details, where can I find them?

See the complete public WebSockets API documentation here:

Reference between pair names in REST API and WebSockets.

This API call gives a map to reference pair names between REST and WebSockets:

wsname = WebSockets pair name (if available)

How to build the “book”?

The book channel supports a feature called “depth republish” where one or more levels beyond the subscribed depth level are republished due to being pulled into scope by lower level deletes. Depth republish updates are indicated by an "r" as the fourth field of the update, and have a timestamp set to the time the level was last updated.

When levels are pushed out of scope beyond the subscribed depth level, they must be deleted from your book as they may be updated whilst out of scope.

For example, consider a user subscribes to XBT/USD with depth 10. A full book snapshot (with all 10 levels on each side) is sent to the user as shown below.

["3823.40000","0.49211000","1552374193.930926"], - Level 1
["3823.30000","0.27900000","1552374196.189126"], - Level 2
["3822.60000","1.00000000","1552374131.646134"], - Level 3
["3822.20000","1.58500000","1552374188.856542"], - Level 4
["3822.00000","1.75000000","1552374199.003082"], - Level 5
["3821.90000","0.29000000","1552374198.689135"], - Level 6
["3821.70000","33.14873600","1552374171.264955"], - Level 7
["3821.60000","0.67000000","1552374201.701587"], - Level 8
["3821.10000","3.01900000","1552374181.687735"], - Level 9
["3821.00000","1.00000000","1552373641.958548"] - Level 10

Sequence of book updates sent in sequential order after initial full book snapshot:

  1. [0,{"b":[["3821.90000","0.00000000","1552374206.005550"],["3820.60000","9.99000000","1552374196.557597","r"]]},"book-10","XBT/USD"]
  2. [0,{"b":[["3821.80000","0.66900000","1552374208.406747"]]},"book-10","XBT/USD"]
  3. [0,{"b":[["3822.20000","0.00000000","1552374210.000754"],["3820.60000","9.99000000","1552374196.557597","r"]]},"book-10","XBT/USD"]

How to interpret above sequence of updates?

  1. Bid delete of 3821.9 at level 6 pulls level 3820.6 which was previously beyond depth 10 into scope (note the "r" field indicating a republish).
  2. Bid insert of 3821.8 at level 6 pushes level 3820.6 out of scope of depth 10.
  3. Bid delete of 3822.2 at level 3 pulls level 3820.6 back into scope (note the "r" field indicating a republish).

Clients are advised not to maintain books beyond the subscribed depth because price levels could be modified while out of scope and an update message would not be sent.