API Upgrade Guide: v1.1 to v3 API Reference

This document provides a guide for v1 API users looking to transition to the v3 API.

Access to and use of the API is governed by our Terms of Service. If you are a user of Bittrex.com, the applicable Terms of Service are available here. If you are a user of Bittrex Global, the applicable Terms of Service are available here.

If you have any API questions, feedback, or recommendations please post a question via our Github page

Getting Started

Version 3 of the Bittrex API (v3) is an evolutionary step up from the previous version 1.1 (v1). Operations that API developers are accustomed to using in v1 typically have a direct corollary in the v3 api. The names of endpoints and fields may be different, but there is broad conceptual alignment across the two versions to help make v3 feel familiar to developers who have worked with the v1 API. From a client technology stack perspective, any client stack which was working with v1 should also be able to work with v3. This document provides both general high level guidance about transitioning from v1 to v3 as well as a detailed mapping of v1 operations and fields to their v3 equivalents.

These steps outline the process to upgrade from v1 to v3:

  1. Read through the New Features and General Information sections of this guide to gain a high level familiarity with what is new and different in v3.
  2. Take an inventory of your usage of the v1 API in your existing code base.
    • Identify operations and data used from v1.
    • Note easy opportunities for improvement based on the new features in v3.
  3. Use the REST API and Websocket API reference portions of this guide to map your v1 API usage to v3 equivalents.
  4. Plan your strategy for replacing v1 dependencies with their v3 equivalents
    • Note: The same engine backs both versions of the API. It is possible to use a mix of v1 and v3 operations while transitioning. Due to the interconnected nature of the v3 REST API and websocket, if a phased transition is desirable, transitioning REST & socket object by object instead of all of REST followed by all of socket may be easier. However the right decision depends on the details of your implementation.
  5. Execute your plan. Be sure to test your v3 implementation with small-value transactions to validate it prior to full production usage.

If you have questions about how something works in v3, be sure to check out the v3 API Reference. If you have additional questions, feedback, or recommendations please post a question via our Github page.

New Features

There are a number of improvements in the v3 API over the v1 API. Some of the highlights are listed below. Additional improvements related to individual v1 operations may be found in the detailed reference sections later in this guide.

REST API:

Websocket:

  • Faster updates
  • Live candle websocket stream
  • Subscribe for deposit updates
  • Easier to consume messages designed to match the REST API
  • Greater control over websocket subscription granularity and the ability to unsuscribe
  • Unified sequence numbers across the REST API and socket for easy synchronization

General Information

This section provides high level comparisons of aspects of the v1 and v3 APIs the cut across multiple operations. For detailed comparisons of individual operations, refer to the REST API and WEBSOCKET reference sections of this guide.

Authentication

Authentication in the v3 API uses the same API keys as were used in the v1 API. Your existing keys will work with the v3 API. The mechanisms for their use are somewhat different.

In the REST API the process for signing request is similar to that of v1, but now also requires a hash of the request body content where applicable. Refer to the REST Authentication documentation for details.

Authentication in the v3 websocket no longer requires getting an auth context prior to authenticating. Instead it uses a client-generated uuid in place of a server generated challenge. It also requires authentication to be renewed periodically for the client to remain subscribed to private streams.Refer to the Authenticating topic in the v3 websocket documentation for additional information.

Authorization

Authorization in the v3 API uses API keys with the same three permission level as were used in the v1 API.

  • View allows retrieving account information but not placing orders or withdrawals
  • Trade allows placing and cancellation of trades
  • Withdraw allows creation and cancellation of withdrawals

RESTfulness

The v1 API used the GET verb for all operations. The v3 API is designed to be RESTful and adheres to the standard definitions of HTTP verbs.

  • GET retrieves information without impacting the state of the system (e.g. view an order)
  • POST creates a new resource (e.g. create an order)
  • DELETE deletes a resource or cancels an operation (e.g. cancels an order)
  • HEAD similar to GET but only retrieves the headers instead of the whole object (e.g. get the current order stream sequence number to make sure you haven't missed anything)

Error Handling

The v1 API included a flag in response bodies indicating if there was an error along with an error code. Error handling in v3 uses HTTP error codes instead of a flag inside of the response body. Details may be found here. In the case of an error, a detailed error code and potentially additional information will be included in the response body. In general, a 4XX series error indicates that the client was at fault (e.g. malformed request, insufficient balance, etc.) while a 5XX series error indicates a server-side issue.

Placing Orders

In v3 there are no longer separate endpoints for buy and sell orders. Order placement has been centralized into POST /orders for orders that execute or are placed on the orderbook immediately and POST /conditional-orders for orders that may execute later based on a condition being met (e.g. stop orders). Conditional orders do not currently have an equivalent in the v1 API so the remainder of this section is focused on regular orders.

Improvements to order placement and management are one area where the v3 API has significant advantages over the v1 API. In addition to supporting many more types of orders, the v3 API supports setting a clientOrderId when placing an order. This id is used as an idempotency key. If reused for order creation within 24 hours, the request will fail with a reference to the existing order. The clientOrderId is stored with created orders forever, but it is no longer enforced after 24 hours.

Another important advantage of the v3 API is that when orders are created or cancelled, the response body will include the current state of the order. This means that it is no longer necessary in v3 to get the order state immediately after placement or cancellation to see what happened when the order hit the book or to get its final state after cancellation.

The configuration options when placing an order have been moved into the body of the POST /orders request. The table below contains a mapping of v1 query parameters to v3 order request fields.

v1 Query Parameter v3 NewOrder Field Notes
direction In v1 the endpoint determined buy vs. sell. In v3 this is an enum (BUY, SELL)
type In v1 only limit orders were supported. In v3 there are a number of different order types. Set type to LIMIT for a limit order.
market marketSymbol Market symbols are reversed in v3 to align with standard forex conventions
quantity quantity
rate limit
timeInForce timeInForce In v1 this could be GTC or IOC. In v3 the equivalent values are GOOD_TIL_CANCELLED and IMMEDIATE_OR_CANCEL. FILL_OR_KILL is also supported in v3.

Additional fields are available in the v3 model that have no equivalent in v1. Refer to the NewOrder schema definition for details.

Websocket Subscriptions

The technical underpinnings of the v3 socket are unchanged from v1. It is still based on Microsoft ASP.net SignalR which should make it easy to transition any existing v1 websocket client implementations to v3. However there are some conceptual differences around subscriptions and message handling.

In v3, subsciptions are arranged around types of resources in the same way that the v3 REST API is organized. For example there is a /balances endpoint that can be used to retrieve Balance objects. For live updates to balances, you subscribe to the Balance stream. Once subscribed, when one of your currency balances changes, you will receive a message with a snapshot of the new balance for that currency. The schema of the payload of that update will be a Balance object just like what is retrieved from the REST API. It will also include a sequence number (the v3 equivalent of a nonce) that matches a sequence number returned in the sequence response header from the GET /balances. This allows usage of the REST API and websocket in concert to maintain a local cache of balance data. All v3 websocket streams follow this general pattern for synchronization.

Additional in v3, websocket messages are no longer minified so there is no need for a mapping table in order to interpret them. Messages are compressed though so decompression is still required before consumption.

REST API

GET /public/getmarkets

Equivalent in v3: GET /markets

The v1 getmarkets request has been replace primarily by the markets endpoint in v3. Some of the fields in the v1 request are actually attributes of a currency, not a market. Those may be found at the currencies endpoint in v3.

v1 Field v3 Object v3 Field Notes
MarketCurrency Market baseCurrencySymbol Market symbols are reversed in v3 to align with standard forex conventions
BaseCurrency Market quoteCurrencySymbol
MarketCurrencyLong Currency name Retrieve from GET /currencies/{baseCurrencySymbol}
BaseCurrencyLong Currency name Retrieve from GET /currencies/{quoteCurrencySymbol}
MinTradeSize Market minTradeSize
MarketName Market symbol
IsActive Market status In v1 this was a boolean flag. In v3 is it an enum (ONLINE, OFFLINE).
IsRestricted Market prohibitedIn In v1 this was a boolean flag. In v3 it is an array of strings indicating prohibited locales.
Created Market createdAt
Notice Market notice
IsSponsored Deprecated
LogoUrl Currency LogoUrl Retrieve from GET /currencies/{baseCurrencySymbol}

GET /public/getcurrencies

Equivalent in v3: GET /currencies

The v1 getcurrencies request has been replaced with the currencies endpoint in v3.

v1 Field v3 Object v3 Field Notes
Currency Currency symbol
CurrencyLong Currency name
CoinType Currency coinType
MinConfirmations Currency minConfirmations
TxFee Currency txFee
Notice Currency notice
IsActive Currency status In v1 this was a boolean flag. In v3 is it an enum (ONLINE, OFFLINE).
IsRestricted Currency prohibitedIn In v1 this was a boolean flag. In v3 it is an array of strings indicating prohibited locales.
BaseAddress Deprecated

GET /public/getticker

The v1 getticker request has been replaced with the market ticker endpoint in v3. In v3 it is also possible to get the tickers for all markets with a single GET /markets/tickers request. Note that when getting a single ticker, the market symbol parameter is reversed in v3 to align with standard forex conventions.

v1 Field v3 Object v3 Field Notes
Bid Ticker bidRate
Ask Ticker askRate
Last Ticker lastTradeRate

GET /public/getmarketsummaries

Equivalent in v3: GET /markets/summaries

The v1 getmarketsummaries request has been replaced primarily with the market summaries endpoint in v3. However some of the fields from the v1 version are either no longer available or found on the ticker or market objects instead.

v1 Field v3 Object v3 Field Notes
MarketName MarketSummary symbol Market symbols are reversed in v3 to align with standard forex conventions
High MarketSummary high
Low MarketSummary low
Volume MarketSummary volume
Last Ticker lastTradeRate Retrieve from GET /markets/tickers
BaseVolume MarketSummary quoteVolume
TimeStamp MarketSummary updatedAt
Bid Ticker bidRate Retrieve from GET /markets/tickers
Ask Ticker askRate Retrieve from GET /markets/tickers
OpenBuyOrders Deprecated
OpenSellOrders Deprecated
PrevDay MarketSummary percentChange In v3 the PrevDay value has been replaced with a rolling 24hr percentChange
Created Market createdAt Retrieve from GET /markets

GET /public/getmarketsummary

The v1 getmarketsummary request has been replaced primarily with the market's summary endpoint in v3. However some of the fields from the v1 version are either no longer available or found on the ticker or market object instead.

v1 Field v3 Object v3 Field Notes
MarketName MarketSummary symbol Market symbols are reversed in v3 to align with standard forex conventions
High MarketSummary high
Low MarketSummary low
Volume MarketSummary volume
Last Ticker lastTradeRate Retrieve from GET /markets/{marketSymbol}/ticker
BaseVolume MarketSummary quoteVolume
TimeStamp MarketSummary updatedAt
Bid Ticker bidRate Retrieve from GET /markets/{marketSymbol}/ticker
Ask Ticker askRate Retrieve from GET /markets/{marketSymbol}/ticker
OpenBuyOrders Deprecated
OpenSellOrders Deprecated
PrevDay MarketSummary percentChange In v3 the PrevDay value has been replaced with a rolling 24hr percentChange
Created Market createdAt Retrieve from GET /markets/{marketSymbol}

GET /public/getorderbook

The v1 getorderbook request has been replaced with the market's orderbook endpoint in v3. The v3 version of the API does not allow you to get only the buy or sell side of the book, but it does allow you to limit the depth returned.

v1 Field v3 Object v3 Field Notes
Buy OrderBook bid Array of OrderBookEntry objects
    Quantity OrderBookEntry quantity
    Rate OrderBookEntry rate
Sell OrderBook ask Array of OrderBookEntry objects
    Quantity OrderBookEntry quantity
    Rate OrderBookEntry rate

GET /public/getmarkethistory

The v1 getmarkethistory request has been replaced with the market's trades endpoint in v3.

v1 Field v3 Object v3 Field Notes
Id Deprecated
TimeStamp Trade executedAt
Quantity Trade quantity
Price Trade rate
Total Deprecated
FillType Deprecated
OrderType Trade takerSide In v1 this was an enum (BUY, SELL). In v3 it is a boolean flag.
Uuid Trade id

GET /market/buylimit

Equivalent in v3: POST /orders

Order placement in the v3 API has been centralized in the orders endpoint. There are many more order type and time in force options than there were in v1. Additionally, the response from posting a new order in v3 returns the full order so there is no need to get the order again after placement to determine its state. Refer to the Placing Orders topic for additional information.

v1 Field v3 Object v3 Field Notes
uuid Order id

The v3 response model for this operation contains the entire order object. Refer to the Order model definition for details.

GET /market/selllimit

Equivalent in v3: POST /orders

Order placement in the v3 API has been centralized in the orders endpoint. There are many more order type and time in force options than there were in v1. Additionally, the response from posting a new order in v3 returns the full order so there is no need to get the order again after placement to determine its state. Refer to the Placing Orders topic for additional information.

v1 Field v3 Object v3 Field Notes
uuid Order id

The v3 response model for this operation contains the entire order object. Refer to the Order model definition for details.

GET /market/cancel

Equivalent in v3: DELETE /orders/{orderId}

Order cancellation in the v3 API is performed via the orders endpoint. The response from cancelling an order in v3 returns the full order so there is no need to get the order again after cancellation to determine its final state. Refer to the Placing Orders topic for additional information.

v1 Field v3 Object v3 Field Notes
uuid Order id

The v3 response model for this operation contains the entire order object. Refer to the Order model definition for details.

GET /market/getopenorders

Equivalent in v3: GET /orders/open

The v1 getopenorders request has been replaced by orders/open in v3. Like the v1 version, in v3 you can filter down to a specific market using a query parameter. In v3 this query parameter is called marketSymbol as opposed to market in v1. Also note that the market symbol in v3 has been reversed to align with standard forex conventions.

v1 Field v3 Object v3 Field Notes
Uuid Deprecated
OrderUuid Order id
Exchange Order marketSymbol Market symbols are reversed in v3 to align with standard forex conventions
OrderType Order type
direction
This field has been decomposed into separate type and direction fields in v3.
Quantity Order quantity
QuantityRemaining Order fillQuantity The v3 API reports quantity filled instead of quantity remaining.
Limit Order limit
CommissionPaid Order commission
Price Order proceeds
PricePerUnit Deprecated
Opened Order createdAt
CancelInitiated Deprecated
ImmediateOrCancel Order timeInForce This boolean flag from v1 has been incorporated into the enum for timeInForce in v3.
IsConditional Conditional orders are a separate concept from orders in v3. Refer to Placing Conditional Orders
Condition Deprecated
ConditionTarget Deprecated

Additional fields are available in the v3 model that have no equivalent in v1. Refer to the Order schema definition for details.

GET /account/getbalances

Equivalent in v3: GET /balances

The v1 getbalances request has been replaced primarily by the balances endpoint in v3. However some of the fields have either been deprecated or can be found under the address endpoint in v3.

v1 Field v3 Object v3 Field Notes
Currency Balance currencySymbol
Balance Balance total
Available Balance available
Pending Deprecated
CryptoAddress Address cryptoAddress Retrieve from GET /addresses
Requested Address status Retrieve from GET /addresses. This boolean flag has been replaced by an enum (REQUESTED, PROVISIONED) in v3.
Uuid Deprecated

The v3 response model for this operation also includes an updatedAt timestamp that has no equivalent in v1. Refer to the Balance schema definition for details.

GET /account/getbalance

Equivalent in v3: GET /balances/{currencySymbol}

The v1 getbalance request has been replaced primarily by the balances endpoint in v3. However some of the fields have either been deprecated or can be found under the address endpoint in v3.

v1 Field v3 Object v3 Field Notes
Currency Balance currencySymbol
Balance Balance total
Available Balance available
Pending Deprecated
CryptoAddress Address cryptoAddress Retrieve from GET /addresses/{currencySymbol}
Requested Address status Retrieve from GET /addresses/{currencySymbol}. This boolean flag has been replaced by an enum (REQUESTED, PROVISIONED) in v3.
Uuid Deprecated

The v3 response model for this operation also includes an updatedAt timestamp that has no equivalent in v1. Refer to the Balance schema definition for details

GET /account/getdepositaddress

The v1 getdespositaddress request has been replaced by the addresses endpoint in v3. One key difference in v3 is that to create a desposit address, you must explicitly send a POST /addresses request for the currency. Another difference is that in v3 it is possible to get your deposit addresses for all currencies with a single GET /addresses request. The v3 version of the API also supports address memos/tags.

v1 Field v3 Object v3 Field Notes
Currency Address currencySymbol
Address Address cryptoAddress

Additional fields are available in the v3 model that have no equivalent in v1. Refer to the Address schema definition for details.

GET /account/withdraw

Equivalent in v3: POST /withdrawals

The v1 withdraw request has been replaced by POST /withdrawals in v3. As with all similar requests, the parameters have been moved into the request body. Additionally, in v3 the response model echos all of the information about the withdrawal. Refer to the POST /withdrawals for details. It is also possible in v3 to attempt to cancel a withdrawal using DELETE /withdrawal/{withdrawalId}.

v1 Field v3 Object v3 Field Notes
uuid Withdrawal id

The v3 response model for this operation contains the entire withdrawal object. Refer to the Withdrawal schema definition for details.

GET /account/getorder

Equivalent in v3: GET /orders/{orderId}

The v1 getorder request has been replaced by GET /orders/{orderId} in v3.

v1 Field v3 Object v3 Field Notes
Uuid Deprecated
OrderUuid Order id
Exchange Order marketSymbol Market symbols are reversed in v3 to align with standard forex conventions
OrderType Order type
direction
This field has been decomposed into separate type and direction fields in v3.
Quantity Order quantity
QuantityRemaining Order fillQuantity The v3 API reports quantity filled instead of quantity remaining.
Limit Order limit
CommissionPaid Order commission
Price Order proceeds
PricePerUnit Deprecated
Opened Order createdAt
Closed Order closedAt
CancelInitiated Deprecated
ImmediateOrCancel Order timeInForce This boolean flag from v1 has been incorporated into the enum for timeInForce in v3.
IsConditional Conditional orders are a separate concept from orders in v3. Refer to Placing Conditional Orders

Additional fields are available in the v3 model that have no equivalent in v1. Refer to the Order schema definition for details.

GET /account/getorderhistory

Equivalent in v3: GET /orders/closed

The v1 getorderhistory request has been replaced by GET /orders/closed in v3. Like the v1 version, in v3 you can filter down to a specific market using a query parameter. In v3 this query parameter is called marketSymbol as opposed to market in v1. Also note that the market symbol in v3 has been reversed to align with standard forex conventions. Additionally, in v3 it is possible to retrieve more history than was possible in v1 by paging back in time. It is also possible filter by the results by date. Refer to the GET /orders/closed documenation and the pagination topic for details.

v1 Field v3 Object v3 Field Notes
Uuid Deprecated
OrderUuid Order id
Exchange Order marketSymbol Market symbols are reversed in v3 to align with standard forex conventions
OrderType Order type
direction
This field has been decomposed into separate type and direction fields in v3.
Quantity Order quantity
QuantityRemaining Order fillQuantity The v3 API reports quantity filled instead of quantity remaining.
Limit Order limit
CommissionPaid Order commission
Price Order proceeds
PricePerUnit Deprecated
Opened Order createdAt
Closed Order closedAt
CancelInitiated Deprecated
ImmediateOrCancel Order timeInForce This boolean flag from v1 has been incorporated into the enum for timeInForce in v3.
IsConditional Conditional orders are a separate concept from orders in v3. Refer to Placing Conditional Orders

Additional fields are available in the v3 model that have no equivalent in v1. Refer to the Order schema definition for details.

GET /account/getwithdrawalhistory

Equivalent in v3: GET /withdrawals/closed

The v3 api offers many more options for retrieving withdrawals than were offered by v1. In v3 you can:

  • Get a list of all requested, pending, etc. withdrawals using GET /withdrawals/open. This operation may be filtered by specific state and currency.
  • Get completed and cancelled withdrawals from GET /withdrawals/closed. In addition to being able to filter by specific state and currency, you can also retrieve a significantly longer history than in v1 by paging back in time. Refer to the pagination topic for details.
  • Get withdrawals by withdawal id or by blockchain transaction id.

In all cases, the response model for an individual withdrawal will be the same. The fields from the v1 getwithdrawalhistory operation map to the v3 model as shown below.

v1 Field v3 Object v3 Field Notes
PaymentUuid Withdrawal id
Currency Withdrawal currencySymbol
Amount Withdrawal quantity
Address Withdrawal cryptoAddress
Opened Withdrawal createdAt
TxId Withdrawal txId
Authorized
PendingPayment
Canceled
InvalidAddress
Withdrawal status The four boolean status flags from v1 have been aggregated into a single status enum field in v3.

Additional fields are available in the v3 model that have no equivalent in v1. Refer to the Withdrawal schema definition for details.

GET /account/getdeposithistory

Equivalent in v3: GET /deposits/closed

The v3 api offers many more options for retrieving deposits than were offered by v1. In v3 you can:

  • Get a list of all deposits pending confirmation using GET /deposits/open. This operation may be filtered by currency.
  • Get completed, orphaned, or invalidated deposits from GET /deposits/closed. In addition to being able to filter by specific state and currency, you can also retrieve a significantly longer history than in v1 by paging back in time. Refer to the pagination topic for details.
  • Get deposits by deposit id or by blockchain transaction id.

In all cases, the response model for an individual deposit will be the same. The fields from the v1 getdeposithistory operation map to the v3 model as shown below.

v1 Field v3 Object v3 Field Notes
Id Deposit id
Amount Deposit quantity
Currency Deposit currencySymbol
Confirmations Deposit confirmations
LastUpdated Deposit updatedAt
TxId Deposit txId
CryptoAddress Deposit cryptoAddress

Additional fields are available in the v3 model that have no equivalent in v1. Refer to the Deposit schema definition for details.

Websocket API

GetAuthContext

The v3 websocket does not require getting an auth context prior to authenticating. As such, there is no v3 equivalent for this operation. To learn about websocket authentication in v3, refer to the Authenticating topic in the v3 websocket documentation.

Authenticate

Like v1, the v3 websocket contains an Authenticate method that must be called prior to receiving user specific updates. Unlike the v1 version, the v3 version uses a client-generated uuid instead of a server generated challenge. Additionally, in v3 authenticating does not automatically subscribe the client for any updates. After authenticating, the client can subscribe authenticated streams as desired. Finally, in v3 authentication must be renewed periodically or the client will be unsubscribed from any authenticated streams. Refer to the Authenticating topic in the v3 websocket documentation for additional information.

The uB and uO messages that resulted from authenticating in v1 have been replaced by the Balance and Order streams in v3, respectively. For a field by field comparison of messages, refer to the two tables below.

Balance Delta - uB

v1 Field v3 Stream v3 Field Notes
Nonce Balance sequence
Uuid Deprecated
AccountId Balance accountId In v1 this was an int. In v3 it is a uuid.
Currency Balance currencySymbol
Balance Balance total
Available Balance available
Pending Deprecated
CryptoAddress Not available via websocket. Use cryptoAddress from GET /addresses instead.
Requested Not available via websocket. Use status from GET /addresses instead.
Updated Balance updatedAt
AutoSell Deprecated

Order Delta - uO

v1 Field v3 Stream v3 Field Notes
AccountUuid Order accountId
Nonce Order sequence
Type Deprecated
Uuid Deprecated
OrderUuid Order id
Id Deprecated
Exchange Order marketSymbol Market symbols are reversed in v3 to align with standard forex conventions
OrderType Order type
direction
This field has been decomposed into separate type and direction fields in v3.
Quantity Order quantity
QuantityRemaining Order fillQuantity The v3 API reports quantity filled instead of quantity remaining.
Limit Order limit
CommissionPaid Order commission
Price Order proceeds
PricePerUnit Deprecated
Opened Order createdAt
Closed Order closedAt
IsOpen Order status This boolean flag from v1 has been replaced by an enum (OPEN, CLOSED) in v3.
CancelInitiated Deprecated
ImmediateOrCancel Order timeInForce
IsConditional Deprecated
Condition Deprecated
ConditionTarget Deprecated
Updated Order updatedAt

QueryExchangeState

The v3 websocket does not support querying. Use the v3 REST API operations for getting the orderbook and getting trades instead. These operations return a sequence number in a header (the v3 equivalent of a nonce) so they can be used for synchronizing state with the server. For more information about synchronizing state in v3, refer to this topic. For a field by field comparison of responses, refer to the below table.

v1 Field v3 Object v3 Field Notes
Buys OrderBook bid Array of OrderBookEntry objects
    Quantity OrderBookEntry quantity
    Rate OrderBookEntry rate
Sells OrderBook ask Array of OrderBookEntry objects
    Quantity OrderBookEntry quantity
    Rate OrderBookEntry rate
Fills Array of Trade objects
    Id Deprecated
    TimeStamp Trade executedAt
    Quantity Trade quantity
    Price Trade rate
    Total Deprecated
    FillType Deprecated
    OrderType Trade takerSide In v1 this was an enum (BUY, SELL). In v3 it is a boolean flag.

QuerySummaryState

The v3 websocket does not support querying. Use the v3 REST API's GET /markets/summaries operation instead. This operation returns a sequence number in a header (the v3 equivalent of a nonce) so it can be used for synchronizing state with the server. For more information about synchronizing state in v3, refer to this topic. For a field by field comparison of responses, refer to the below table.

v1 Field v3 Object v3 Field Notes
MarketName MarketSummary symbol Market symbols are reversed in v3 to align with standard forex conventions
High MarketSummary high
Low MarketSummary low
Volume MarketSummary volume
Last Ticker lastTradeRate Retrieve from GET /markets/tickers
BaseVolume MarketSummary quoteVolume
TimeStamp MarketSummary updatedAt
Bid Ticker bidRate Retrieve from GET /markets/tickers
Ask Ticker askRate Retrieve from GET /markets/tickers
OpenBuyOrders Deprecated
OpenSellOrders Deprecated
PrevDay MarketSummary percentChange In v3 the PrevDay value has been replaced with a rolling 24hr percentChange
Created Market createdAt Retrieve from GET /markets

SubscribeToExchangeDeltas

The v1 SubscribeToExchangeDeltas operation has been replaced in v3 by subscribing to the Orderbook and Trade streams. One advantage of the v3 Orderbook stream is that it allows some control over the depth of the orderbook about which to receive updates. Refer to the stream's documentation for details.

Market Delta - uE

v1 Field v3 Stream v3 Field Notes
MarketName Orderbook
& Trade
marketSymbol Market symbols are reversed in v3 to align with standard forex conventions
Nonce Orderbook
& Trade
sequence
Buys OrderBook bidDeltas Array of OrderBookEntry objects
    Type Deprecated. In v3 quantity equal to 0 indicates the entry should be removed.
    Quantity OrderBook quantity
    Rate OrderBook rate
Sells OrderBook askDeltas Array of OrderBookEntry objects
    Type Deprecated. In v3 quantity equal to 0 indicates the entry should be removed.
    Quantity OrderBook quantity
    Rate OrderBook rate
Fills Array of Trade objects
    FillId Trade id In v1 this was an int. In v3 it is a uuid.
    TimeStamp Trade executedAt
    Quantity Trade quantity
    Rate Trade rate
    OrderType Trade takerSide In v1 this was an enum (BUY, SELL). In v3 it is a boolean flag.

SubscribeToSummaryDeltas

The v1 SubscribeToSummaryDeltas operation has been replaced in v3 by subscribing to the Market Summaries and Tickers streams. These streams will return data for all markets. Additionally in v3 it is possible to subscribe for updates about individual markets by using the Market Summary and Ticker streams.

Summary Delta - uS

v1 Field v3 Stream v3 Field Notes
Nonce MarketSummaries
& Tickers
sequence In v3 sequence is only included with Market Summaries and Tickers subscriptions. Individual Market Summary and Ticker subscriptions do not include a sequence number because each message is a full snapshot.
MarketName MarketSummaries
& Tickers
symbol Market symbols are reversed in v3 to align with standard forex conventions
High MarketSummaries high
Low MarketSummaries low
Volume MarketSummaries volume
Last Tickers lastTradeRate
BaseVolume MarketSummaries quoteVolume
TimeStamp MarketSummaries updatedAt
Bid Tickers bidRate
Ask Tickers askRate
OpenBuyOrders Deprecated
OpenSellOrders Deprecated
PrevDay MarketSummaries percentChange In v3 the PrevDay value has been replaced with a rolling 24hr percentChange
Created Not available via websocket. Use createdAt from GET /markets instead.

SubscribeToSummaryLiteDeltas

The v3 websocket does not have lighter versions of its summary delta equivalents: the Market Summary and Ticker streams. Instead it offers the ability to subscribe to them on a market by market basis using the Market Summary and Ticker streams.

Lite Summary Delta - uL

v1 Field v3 Stream v3 Field Notes
MarketName MarketSummary
& Ticker
symbol Market symbols are reversed in v3 to align with standard forex conventions
Last Ticker lastTradeRate
BaseVolume MarketSummary quoteVolume
PrevDay MarketSummaries percentChange In v3 the PrevDay value has been replaced with a rolling 24hr percentChange