Exchange API

Verifying an API

Sometimes we need to determine if an exchanges API is currently operating or not. The following steps should allow you to verify if an API is working.

Step 1: Check the Connection

Inside the API setup form, there is a field called "Is exchange connected". This field is checked when the software has accepted and stored your connection/authentication credentials. So if this is checked then in theory you should be proceed to the next step. If this field is not checked then you have to enter the your API credentials.

API credentials can be deleted by the software in case the credentials are wrong. If the software has tried to connect 3 times and all 3 times has failed, then and only then can the API credentials be deleted by the software itself.

A connection to an exchange API is not accepted if there are no coins present on the exchange. It is a bit of strange rule, but we do not accept wallets that return empty (for checking the connections) because it might indicate the API is not running and therefore you could get a false reading. So we have hardcoded a limit for this. There must be at least a cent/satoshi/minimal amount of an altcoin inside your wallet to allow the API connection.

Additional information about the connection and related messages is available inside the software its log viewer.

Step 2: Check the Wallet

As soon as an exchange API is connected to HTS it will read the wallet. This wallet update is done almost every minute, depending on how many bots you have running. It can scale to update more or less often. Usually, the wallet updates at least once minute.

Usually, the wallet will always display the coins you have on the exchange. There are a few situations where this might not be the case.

1. The API has timed out and the wallet temporarily cannot update its contents.

2. The API has dropped the connection and therefore the wallet could not update.

In both cases, there is nothing you can do except wait. The software is able to update the wallet contents once the connection is restored. In general, if the wallet contents are not present/updated, we recommend to check it again after 5 or 10 minutes. Generally, it is expected that everything will update when the connection is restored.

If the situation arises where the wallet contents are not updating, two things can be done. The API credentials can be setup again, forcing the connection to refresh, or a simple restart of the software can resolve it. If both of these options fail, it is recommended to contact us for support.

If the wallet reading malfunctions because an API update, there should be an error message inside the software logs.

Step 3: Check Trading

Once we have made sure the connection is valid and the wallet is updating in HTS, we can proceed by checking the trade commands to the API.

In order to do this, we have to setup a trade bot. Of course, the bot must have coins, the trade-amount must be correct and the coin position must be valid.

You should be able to press the "Buy now" or "Sell now" button (depending on your coin position of course). This will place your order. You will see a notification confirming the order. The bot’s log will record the forced trade, and the software’s logbook will save any details of the trade.

We expect that this trade will happen normally. If it does not please proceed with the next 2 questions:

1. Does the account have any coins to trade?

2. Are the trade-amount and coin position valid?

If you are certain that this is accurate, then we must find out why the trade did not execute. To do so, check the bot’s debug log to see why the trade has failed. The software logs should also be checked for any related messages. The software logs should have recorded the exact details of the trade and any reason it may have failed.

API Time-out

HTS works based on its own framework. This framework and the stability of it is checked daily using automated unit tests, and this way we are sure it works as it should be. However, the underlaying API drivers are most of the times the cause of instability and therefore they have their own error handling system.

These handling systems are located within the drivers itself as they are developed and controlled by the HaasOnline Software Team. We set the rules of whats acceptable or not. Of course, this is not as easy as it appears and therefore we have described the situations that may happen and how we handle it within the driver models.

Communication Rules & Limits

Execution time measurements

• If we measure a response time of greater then 1 minute for more then 6times in a hour -> 5min timeout

• If we measure a response time of greater then 30seconds for more then 24times -> 5min timeout

• If we measure an average response time of greater then 90seconds -> 5minute timeout

We measure (and reset) this during the peak times each hour. When a timeout occurs, then we know an exchange’s API is unstable, so we "reset" the counter to half and we will retry everything after the timeout is completed.

HTML error handling

Error	Description
HTML-403 (access denied)	5-minute timeout (likely flagged as DDoS attack)
HTML-522 (cloudflare)	2-minute timeout (CloudFlare is protecting now)
HTML-1010 (cloudflare)	Total block, software is banned at CloudFlare
HTML-1006,1007,1008 (cloudflare)	Total block, user IP is banned, issue big error

Connectivity Handling

Error	Description
DNS Errors	Small timeout to give the DNS a little room

Exchange Error Handling

Error	Description
Invalid key found	Give warning and disconnect
Nonce	Do reconnect protocol
Limit orders disabled	Give warning only
Market orders disabled	Give warning only
Trade-amount too low on orders	Give warning only
Trade-amount too high on order	Give warning only