Take a look at our next software release and other upcoming features and improvements.

For the latest API updates, see our release notes or subscribe to our RSS feed.

What's in the next release?​

The next release is version 2.10.0. We expect this to include the following changes:

New​

Timestamps with nanosecond precision​

For the following requests, we will add 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

After these parameters are live, we plan to deprecate the existing timestamps that use millisecond precision as part of a future release. 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 will 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: your limit, stopLoss, or takeProfit order has expired because there was no match, enough liquidity in the order book, or the timeInForce conditions have not been met. Your market order can also expire if you don't have enough balance on your account.
• canceled: your order has been cancelled by either you or Bitvavo. You can find the cancellation reason under the returned restatementReason parameter implemented in v2.9.0.

What you need to do​

• Update your integration to use the new nanosecond-precision timestamp parameters (*Ns). Plan to move away from using millisecond-based timestamp parameters in your systems.
• Update your logic to handle the 200 OK response status code with "price": null and modify any logic that handles HTTP 500 for missing ticker prices.
• Update your completed orders logic to be able to handle the new order status values and consume the cancellation reasons from the restatementReason parameter.

Coming soon​

In September 2025, we plan to release version 2.11.0. Besides other updates, this release will include:

Breaking change: Tick size validation​

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

What is changing​

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

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

Why is this beneficial​

This validation will help:

• Keep the order book clean and consistent.
• Setting 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 tha your app creates and updates orders with prices that are multiples of the tick size for the market you are trading on.

You can find the tick size for each market in the response to the Get markets REST or WebSocet request.

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

Changed​

Performance improvements​

To improve performance when making update and cancel order requests:

• We no longer return HTTP 400 with the error code 233 for orders that have been canceled or fully filled.
• We now return HTTP 404 with error code 240 for all Not Found scenarios, including orders that are no longer active.

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.

New​

Transaction history endpoint​

We have added a new Transaction History endpoint to retrieve the transaction history of your account. You can filter transactions by type and date range.

New​

Market fees endpoint​

We have added a new Fees endpoint to retrieve the transaction costs you are charged for trading in a specific market.

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.

Changed​

Rate limits update​

We updated the Rate limits policies.

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.

New​

Advanced order types​

We added stopLoss, stopLossLimit, takeProfit, and takeProfitLimit order types.

Account endpoints​

We added the Account endpoints.

New​

Asset networks​

We added networks to assets.

New​

Enhanced ticker data​

• Added bestBidSize and bestAskSize to the tickerBook and the WebSocket ticker.
• Added bestBid, bestBidSize, bestAsk, bestAskSize, and timestamp parameters to ticker24h.

Trade and order parameters​

• Added the tradeIdFrom, tradeIdTo, orderIdFrom, and orderIdTo parameters to limit returned trades and orders (deprecating tradeId orderId in those searches).

WebSocket stream​

• Added a ticker24h WebSocket stream.

New​

Order ID in user trades​

Added orderId to user trades.