This document details use of Kraken's REST API for our Spot exchange. The Spot exchange Websockets API and the Kraken Futures APIs are documented separately. Our REST API is organised into publicly accessible endpoints (market data, exchange status, etc.), and private authenticated endpoints (trading, funding, user data) which require requests to be signed.

Your use of the Kraken REST API is subject to the Kraken Terms & Conditions, Privacy Notice, as well as all other applicable terms and disclosures made available on www.kraken.com.

Further information and FAQs may be found on the API section of our support pages. If you have trouble making any standard requests that our system permits, please send us a ticket with a full copy of the request(s) that you're attempting, including your IP address and all headers, so that we may investigate further.

Requests

Request payloads are form-encoded (Content-Type: application/x-www-form-urlencoded), and all requests must specify a User-Agent in their headers.

Responses

Responses are JSON encoded and contain one or two top-level keys (result and error for successful requests or those with warnings, or only error for failed or rejected requests)

Example Successful Response

{
  "error": [],
  "result": {
    "status": "online",
    "timestamp": "2021-03-22T17:18:03Z"
  }
}

GET https://api.kraken.com/0/public/SystemStatus

Example Rejection

{
  "error": [
    "EGeneral:Invalid arguments:ordertype"
  ]
}

Error Details

HTTP status codes are generally not used by our API to convey information about the state of requests -- any errors or warnings are denoted in the error field of the response as described above. Status codes other than 200 indicate that there was an issue with the request reaching our servers.

error messages follow the general format <severity><category>:<error msg>[:add'l text]

• severity can be either E for error or W for warning
• category can be one of General, Auth, API, Query, Order, Trade, Funding, or Service
• error msg can be any text string that describes the reason for the error

Some Common Examples

Additional information can be found on our support center.

Authenticated requests must include both API-Key and API-Sign HTTP headers, and nonce in the request payload. otp is also required in the payload if two-factor authentication (2FA) is enabled.

nonce

Nonce must be an always increasing, unsigned 64-bit integer, for each request that is made with a particular API key. While a simple counter would provide a valid nonce, a more usual method of generating a valid nonce is to use e.g. a UNIX timestamp in milliseconds.

Note: There is no way to reset the nonce for an API key to a lower value, so be sure to use a nonce generation method that won't produce numbers less than the previous nonce. Too many requests with invalid nonces (EAPI:Invalid nonce) can result in temporary bans. Problems can arise from requests arriving out of order due to API keys being shared across processes, or from system clock drift/recalibration. An optional "nonce window" can be configured to specify a tolerance between nonce values. Additional info can be found in our support pages.

otp

If two-factor authentication (2FA) is enabled for the API key and action in question, the one time password must be specified in the payload's otp value.

We have various safeguards in place to protect against system abuse, order book manipulation, DDoS attacks, etc. For REST API requests, these are broadly organised into rate limits specific to the REST API, and rate limits which apply to any trading requests.

Note: For clients with performance sensitive applications, we strongly recommend the use of our Websockets API for minimising request latency and receiving real-time information, reducing or eliminating the need to frequently poll REST endpoints.

Limits

Every REST API user has a "call counter" which starts at 0. Ledger/trade history calls increase the counter by 2. All other API calls increase this counter by 1 (except AddOrder, CancelOrder which operate on a different limiter detailed further below).

The user's counter is reduced every couple of seconds depending on their verification tier. Each API key's counter is separate, and if the counter exceeds the maximum value, subsequent calls using that API key would be rate limited. If the rate limits are reached, additional calls will be restricted for a few seconds (or possibly longer if calls continue to be made while the rate limits are active).

Note: Master accounts and subaccounts will share the same default trading rate limits as determined by the master account's tier.

Errors

• "EAPI:Rate limit exceeded" if the REST API counter exceeds the user's maximum.
• "EService: Throttled: [UNIX timestamp]" if there are too many concurrent requests. Try again after [timestamp].

Additional information can be found on our support center.

Limits

Separate limits apply to the number of orders clients may have open in each pair at a time, and the speed with which they may add and cancel orders in each pair. These limits vary by the account verification tier:

Penalties

The speed is controlled by a ratecounter for each (client, pair) which starts at zero, is incremented when penalties are applied, and decremented according to the decay rates above. A penalty is added to the ratecounter for each new order placed (AddOrder) or cancelled (CancelOrder, CancelAll, CancelAllOrdersAfter) on the pair. The cancellation penalty varies according to the lifetime of the order.

*** n is number of orders in batch

** Rate limits penalty for CancelOrderBatch will be cumulative sum of individual orders penalty, accumulated upto max ratecount. In case, the cumulative penalty in the batch exceeds max ratecount, cancel requests in batch are still accepted.

Note: A client's exact ratecounter values can be monitored via the Websockets openOrders feed.

Errors

• "EOrder:Orders limit exceeded" if the number of open orders in a given pair is exceeded
• "EOrder:Rate limit exceeded" if the user's max ratecount is exceeded for a given pair

Additional information can be found on our support center.

• May 2023 - Added address parameter to Withdraw.
• Mar 2023 - Added originators paramater to DepositStatus.
• Feb 2023 - Added long and short margin position limits to AssetPairs.
• Feb 2023 - Specified minimum and maximum number of txids and userrefs for CancelOrderBatch.
• Feb 2023 - Specified maximum number of responses for DepositStatus and WithdrawStatus.
• Feb 2023 - Note to use %2b instead of + for URL encoding in AddOrder starttm and expiretm parameters.
• Jan 2023 - Removed requirement for asset in DepositStatus and WithdrawalStatus.
• Jan 2023 - Documented reduce_only parameter in AddOrder and AddOrderBatch.
• Jan 2023 - Added consolidate_taker to TradesHistory and QueryTrades.
• Jan 2023 - Added User Subaccounts section with CreateSubaccount and AccountTransfer endpoints.
• Jan 2023 - Added trade_id to private TradesHistory.
• Dec 2022 - Fixed pair parameter restriction on TradeVolume.
• Dec 2022 - EditOrder allowed on margin orders.
• Nov 2022 - Added tick_size and status parameters to AssetPairs, status and collateral_value to Assets, and trade_id to public Trades.
• Oct 2022 - Documented uv (unexecuted value) field in TradeBalance.
• Oct 2022 - Added costmin trading parameter to AssetPairs.
• Oct 2022 - Ticker wildcard support - pair no longer required, no pair parameter returns tickers for all tradeable exchange assets.
• Sep 2022 - AddOrder/EditOrder/AddOrderBatch now support icebergs.
• July 2022 - Added support for restricting API keys to specified IP address(es)/range.
• June 2022 - Added custom self trade prevention options.
• May 2022 - New REST AddOrderBatch endpoint to send multiple new orders and CancelOrderBatch endpoint to cancel multiple open orders.
• Mar 2022 - New REST EditOrder endpoint to edit volume and price on open orders.
• Dec 2021 - Add REST AddOrder support for optional parameter trigger and values last (last traded price) and index.

Note: Most changes affecting our APIs or trading engine behaviour are currently being tracked on our Websockets changelog, until these documents are combined.

In order to achieve maximum performance, security and flexibility for your particular needs, we strongly encourage the implementation of this API with your own code, and to minimise reliance on third party software.

That being said, in order to aid with rapid development and prototyping, we're in the process of producing 'official' API clients in Python and Golang that will be actively maintained, coincident with the release of newer versions of both our Websockets and REST APIs. In the meantime, our Client Engagement team has compiled a number of code snippets, examples and Postman collections that many find useful.

Third Party Software

Below are other third party API client code libraries that may be used when writing your own API client. Please keep in mind that Payward nor the third party authors are responsible for losses due to bugs or improper use of the APIs. Payward has performed an initial review of the safety of the third party code before listing them but cannot vouch for any changes added since then, or for those that may be stale. If you have concerns, please contact support.

Other