9 posts tagged with "websocket"

Breaking change​

Tick size validation introduced​

Tick size is the smallest increment in the price of a crypto asset that you can change or quote on Bitvavo.

What is changing​

For every market, we now determine the minimum price increment that can be made on Bitvavo. When the price is set, we validate that the price is a multiple of the tick size. If it is not, we return an error.

For example, if the tick size is 0.01, you can only set the price to 1.00, 1.01, 1.02, and so on. If you try to set the price to 1.005, we return an error.

Why is this beneficial​

This validation helps:

• Keep the order book clean and consistent.
• Set precise prices for large orders or crypto assets like Bitcoin, which have a high tick size.
• Minimize the risk of rapidly undercutting existing orders by the smallest possible amount.

What you need to do​

Make sure that your app creates and updates orders with prices that are multiples of the tick size for the market you are trading on. To get the tick size, you can make Get markets REST or WebSocket requests.

Deprecated​

pricePrecision​

With the tick size validation, the pricePrecision response parameter of the Get markets REST and WebSocket requests now always returns the value null. We will remove this parameter in one of the next releases.

New​

Cancel on disconnect​

In case of network disconnections, extreme latency, or similar issues your orders can remain open and be filled at unfavorable prices while you are disconnected.

To prevent this, you can now use an optional feature, Cancel on disconnect. This automatically cancels your open orders if there is no activity from you for a set period of time.

To enable this, we have added a new type of request that lets you create groups of orders. Check out our WebSocket and REST API endpoints to learn more.

Timestamps parameters for orders​

For the following requests, we added two new timestamp parameters:

Request / Message	Parameter name
Get order response REST and WebSocket	createdNs, updatedNs
Get orders response REST and WebSocket	createdNs, updatedNs

For now, these parameters still return the timestamps in microseconds and populate the rest of the signature with zeros. In a future release, we will increase the precision to nanoseconds.

New​

Timestamps with nanosecond precision​

For the following requests, we added new timestamp parameters with nanosecond precision:

Request / Message	Parameter name
Get server time REST and WebSocket	timeNs
Create order response REST and WebSocket	createdNs, updatedNs
Update order response REST and WebSocket	createdNs, updatedNs
Get open orders response REST and WebSocket	createdNs, updatedNs
Trades subscription trades event	timestampNs
Track your orders fill event	timestampNs
Track your orders order event	createdNs, updatedNs

In a future release, when all users have switched to using nanosecond precision, we will deprecate the existing timestamps that use millisecond precision. We will announce this in advance, so you can prepare for it.

Changed​

Get ticker price​

For the Get ticker price REST and WebSocket requests, when there is no price available, we now return HTTP 200 response with "price": null instead of an HTTP 500 error.

Completed orders status changes​

In the lifecycle of an order, completed orders can now only have the following statuses:

• filled: all trades necessary to complete the order have been filled.
• expired: the order never gets added to the order book because there is no match, enough liquidity in the order book, or enough balance in your account. Also, if you set the timeInForce parameter to IOC or FOK for your order, the order can expire if those conditions are not met.
• canceled: the orderId is removed from the order book by either you or Bitvavo.

We now return the specific reasons for cancellation using the restatementReason response parameter. To learn more, see Canceled orders.

New​

Fill amounts in WebSocket order events​

To allow you to track the filled amounts for your orders and calculate the average fill prices, we added the following parameters to the order event of the Track your orders WebSocket channel:

• filledAmount: The amount of the base currency that was filled.
• filledAmountQuote: The amount of the quote currency that was filled.

Execution type indicator in WebSocket events​

In the order event of the Track your orders WebSocket channel, we added an executionType parameter to indicate how the order was updated. Depending on the type, it can have one of the following values: new, trade, canceled, expired, updated, triggered, or restated.

MiCA report endpoints​

To comply with the EU's Markets in Crypto-Assets (MiCA) regulation, we added the Get order book report and Get trades report endpoints to the REST API. You can now get the order book and trades reports for a specific market and date range with additional details.

Changed​

HTTP status code when market data is unavailable​

We now return a more specific HTTP status code when market data is not available. If the market is in a halted, auction, or auctionMatching status and you send a Get order book request, we now return 409 Conflict instead of 503 Service Unavailable.

In this case, there is a conflict with the current market status, not the availability of the service.

Operator ID is now a required parameter​

The operatorId is now be a required request parameter in the following requests:

• REST API: Create order, Update order, Cancel order, and Cancel orders.
• WebSocket API: Create order, Update order, Cancel order, and Cancel orders.

Failing to specify the operatorId in the request now results in an error response.

Reason for order status change​

We added a new restatementReason parameter to specify the reason for the order status change, for example when an order is canceled by the Price protection checks. This parameter is returned in the responses and events of the following requests:

• REST API: Create order, Update order, Get order, Get orders, and Get open orders.
• WebSocket API: Create order, Update order, Get order, Get orders, Get open orders, and Track your orders.

Removed​

orderId query parameter​

We removed the deprecated orderId query parameter from the Get orders REST API request.

tradeId query parameter​

We removed the deprecated tradeId query parameter from the Get trades REST API and WebSocket API requests.

New​

Timestamps in order book snapshots​

• For the Get order book REST request, we added a timestamp of when the snapshot was generated.
• For the Get order book WebSocket action, we added a timestamp of the last transaction event.
• For the WebSocket Book subscription channel, we added a timestamp of the last transaction event in the message.

Response parameters for Get markets​

The responses to the GET /markets REST and WebSocket requests now include the following parameters:

• quantityDecimals (integer)
• notionalDecimals (integer)
• tickSize (string)
• maxOpenOrders (integer)
• feeCategory (string)

Changed​

New market statuses​

We updated the market status logic and added two more statuses in the lifecycle of orders:

• trading: open for trading.
• halted: closed for trading. You cannot create, update, or cancel orders.
• auction: in transition from closed to open. You cannot create market orders. You can create other order types, but there is still no matching.
• auctionMatching: the opening price is calculated. Orders created during the auction phase that meet the final opening price are matched and executed.
• cancelOnly: you can only cancel orders and cannot create or update orders.

Operator ID response parameter​

If specified, the operatorId parameter is now returned in the responses to the following requests:

• REST API: Create order, Update order, Cancel order, and Cancel orders
• WebSocket API: Create order, Update order, Cancel order, and Cancel orders

New​

Operator ID parameter​

We added a new request parameter: operatorId to uniquely identify different traders or trading bots that trade from your account. This parameter is available in the following requests:

• REST API: Create order, Update order, Cancel order, and Cancel orders
• WebSocket API: Create order, Update order, Cancel order, and Cancel orders

New​

Error codes​

• For HTTP 400: Bad Request, we now return an error code 429 when a parameter value has too many decimal places. The number of decimal places can vary per market.
• For HTTP 503: Service Unavailable, we now return error codes:
  • 430 when a connection times out because no new market data events are received.
  • 431 when we cannot retrieve data for a market because it isn't in a trading status.

Changed​

API updates​

• When making an Update order request, the fills object in the response now only includes the fills generated by the request instead of all historical fills for the specified orderId.
• In the Create Order request, Update Order, and Cancel Order requests, the clientOrderId must only have a unique identifier among the open orders of that user. When the orders are closed, you can reuse that clientOrderId.
• Specifying the clientOrderId query parameter in the Get order request now only returns the latest order for that clientOrderId.
• When making a Get orders request, the value of the clientOrderId is only returned for the latest order of the same clientOrderId. The values for earlier orders that used that clientOrderId is null.
• The Get balance request now only returns the assets that have a balance greater than 0.
• When retrieving the order book or subscribing to ticker and book endpoints, the data is now only returned for the markets that are in a trading status.
• When making a Get order book request, the maximum depth of bids and asks to retrieve in a single request is now 1000.

Deprecated​

Features to be removed​

• The Get open orders request now returns an empty fills object instead of all historical fills for the specified orderId. This parameter will be removed in the next version.
• When creating a new order, setting the disableMarketProtection parameter no longer works. If included, the request does not fail, but it ignores the parameter.

Changed​

Client order ID tracking improvements​

We improved tracking of order status with the clientOrderID parameter:

• Update and Cancel orders now have a unique clientOrderId. You can set this ID for every Create order.
• clientOrderId is returned in the response for the Trading subscription WebSocket.

New​

Client order ID​

You can now set a unique clientOrderId for every new order. You use this ID to easily track the order status.

WebSocket request ID​

You can set a unique requestId to an initial WebSocket request. This value is added to the return parameters for the action.