Skip to main content

Frequently asked questions

Trading​

Are order and cancel requests via WebSocket faster than via REST calls?

Yes, according to our measurements, WebSocket is faster than REST.

According to the docs, there's a TimeInForce field in the update message. Is it possible to insert a GFD and later amend the TimeInForce?

No, it is not possible to amend the TimeInForce. We don't have a GFD, its GTC by default.

Can you please clarify the following transaction types returned by the transaction history endpoint.

The transaction of some types are:

  • staking - rewards that are distributed to users who have opted-in.
  • internal_transfer - used to allow users to move funds between accounts. We no longer log these types of transactions.
  • external_transferred_funds - this is related to Litebit. Users who have their funds transferred over from Litebit will have these types of transactions.
Do you have any documentation on failure responses for REST or WebSocket requests?

Yes. See our docs about error handling.

How do I request my available euro balance using the API? Should I use the Account balance endpoint with EUR symbol?

Yes! You can use the GET /balance request.

I am trying to connect to Bitvavo and found that rejection messages for the orders do not have any information about which order was rejected.

When you subscribe to an account channel and it doesn't have any rejection messages it can be hard to distinguish orders in WebSocket:

{
  "action": "privateCreateOrder",
  "market": "BTC-EUR",
  "errorCode": 216,
  "error": "You do not have sufficient balance to complete this operation."
}

To counter this, you can add a requestId to the request to trace the order.

Is it possible to increase the rate limit of my API key?

When you are ready for high volume trading, send a request to our Support Team and specify the volume of trading you expect to make. We will be happy to accommodate you. The more you trade, the cheaper it is to trade on Bitvavo. See our market fees here.

I would like to understand whether I will see the nonce value reset/decrease during the lifetime of a WebSocket session.

The nonce value should never decrease during the lifetime of a matching engine. However, it is reset when the engine is restarted. This means t hat you can expect that nonce could be reset during the lifetime of WS sessions.

In trades, there is timestamp (milliseconds). Is it matching engine time?

It’s the time when the trade occurred in UTC.

Is restarting the matching engine common or a part of a scheduled downtime?

Usually the restart of the matching engine (ME) happens during the scheduled downtime, but tt can happen that something goes wrong and the ME needs to be restarted. See our Status page.

Is there an API endpoint for getting scheduled downtime announcements?

At the moment we don't have such an endpoint.

My trading bot often incorrectly gives a minimum value error message. How often is this minimum value adjusted to match current market values?

To find the minimum amount for a transaction, make a Get market data request and use the minOrderInBaseAsset and minOrderInQuoteAsset values from the response. Then check the value against your balance. For high frequency trading, remember that when you make an order on Bitvavo, the onHold amount of the onHoldCurrency is blocked. After the trades are completed, there is a slight lag until the trading fees are charged.

WebSocket​

Are the response samples in the API docs the same for Websocket responses?

Yes, the response samples are the same for WebSocket and REST APIs.

Are the WebSocket updates published to any subscribed session identical in terms of their payload?

For example, for two sessions subscribed to BTC-EUR, will they always receive the same updates containing the same nonce value, and exact same price updates? It is the expected behavior that all clients receive the same updates.

Can I rely on a deterministic ordering of fill and order events? For example, when a fill occurs on Bitvavo, does a WebSocket session see an order, then fill event (or vice versa)? Will this ordering always be consistent?

We don't provide any guarantees for ordering here, unfortunately. We have a distributed and concurrent environment, so sometimes we have to sacrifice determinism in favor of minimizing latency.

If a matching engine (ME) is restarted (causing the nonce to decrease), would any existing market data WebSocket (WS) connections be disconnected or do WS connections stay connected while the ME is restarted?

WS will stay connected. WS can be used for different markets and actions.

Is it delta update for the full book for WebSocket book subscription or is it limited to some range?

We don't limit the depth for the order book event, we handle the event as we get it from a matching engine (ME).

Is it guaranteed that a fill-event from the WebSocket trading subscription will be received only after a response for createOrder event?

You might want to set the responseRequired flag to false when you create an order to get the minimal acknowledgement of success or failure ASAP (along with the orderId). It's technically possible for a fill event to happen before a createOrder response even if responseRequired is set to false because these are two separate processes. But typically setting the flag to false results in a much faster response time, so it's very unlikely that a fill event precedes an order response.

Is it possible for a fill event to be faster than order event?

There is no ordering guarantee in a matching engine (ME) at the moment as to which response will be sent first. Under normal conditions it should be the createOrder response first as fill event is sent on settlement but there are no guarantees.

Is there any benefit to authenticating WebSocket connections used for receiving market data events?

The rate limits are higher for authenticated users.

Is there any speed advantage when using an authenticated WebSocket connection if I only use endpoints that don't require authentication.

No, there is no speed advantage. But it is better to use an authenticated WebSocket connection to have proper rate limits.

Sometimes when I am losing some of my WebSocket connections, and I am trying to reconnect I receive the following errors: Handshake status 429 Too Many Requests

It's good to check whether the reconnection is attempted in multiple threads, or on a loop without waiting for the response of the server. Also, check if you are sharing the IP with someone else, for instance a private VPN network.

What is the behavior of Bitvavo API if a market data WebSocket consumer cannot keep up with the rate of updates being published by API? Will the packets be dropped by API side (leading to a gap in the nonce value), or disconnect the connection?

WebSocket(WS) is built on top of TCP. All packets are delivered in order and there's checks for packet loss. The server can buffer messages to a point, but since WS operates over TCP the server doesn't drop packets. Messages not being processed are usually due to client-side limitations or network issues, not server-side packet drops. If the buffer fills up, the server might slow down the message rate or as a last resort disconnect the connection. For reconnection and buffered messages, consumers should implement appropriate handling.

What is the maximum number of Websocket connections one account can open?

We don't have a limit in place but the rate limit is shared between all open connections.

When I subscribe to messages using WebSocket, do I need to do that via a REST call? Is it also possible to send a subscription message directly over the WebSocket?

WebSocket protocol works over HTTP. You need to open a WebSocket connection and send the request with actions that you want. See the WebSocket docs. You could also use one of our SDKs.

Withdrawals​

Is it possible to transfer transaction costs in euros internally via the API? So from one Bitvavo user to another Bitvavo user?

Unfortunately, this is not possible. You can only transfer digital assets between internal wallets. Euro transactions are sent to your IBAN which is external to Bitvavo. Fees for any transaction on Bitvavo are charged just after the operation has taken place. For example, after a trade takes place or a is transaction made. In the case of asset withdrawal, see the internal and addWithdrawalFee parameter in POST methods.

I read in the documentation that it is necessary to disable the cryptocurrency withdrawal lock to allow withdrawals to external wallets. However, I noticed that even with this lock activated, transfers to internal wallets on Bitvavo are also not possible.Is there a way to facilitate internal transfers without disabling this lock?

To withdraw assets using the API you have to assign the Withdraw digital assets permission to your API key. When you withdraw using the API 2FA and address confirmation by e-mail are disabled.

Withdrawals of digital coins, both internally and externally, can only take place if a crypto address has been added to the address book. How does that work with an internal transfer, from one Bitvavo user to another?

You should set the wallet address in POST /withdrawal.

Rate limits​

Is there a weight difference in a WebSocket subscription request if I subscribe to multiple markets in a single request?

No. The difference in the request composition is only for ticker24 and open orders. They are more expensive if no market is specified.

What is the weight of a WebSocket subscription request and is it different per subscription? Does the OrderBook have a different weight from Ticker or Trades?

No, they all have the default point. You can find the exact weight of each request in the API docs.