Hello.

I would like to report what appears to be an error in the following endpoints of the Gate.io REST API:

• /spot/currencies
• /spot/currencies/{currency_symbol}
• /wallet/currency_chains

The above endpoint returns all currencies listed in Gate.io along with info on wallet deposit/withdrawal status and default chain name, but the following 5 currencies lack info on chain names:

1. OAK
2. IOTA
3. KAPEX
4. SO
5. TNKR

I would like to know why chain names are missing for those currencies, and would like the error solved in the near future.

Thank you.

Hello Gate.io Support Team,

1st I'm following below URL which is official documentation provided by
Gate.io

https://www.gate.io/docs/apiv4/en/#apiv4-signed-request-requirements

I'm running below API in Postman and I'm getting below response. Can you
please help me how to sign the API request.

Response

I'm getting below error while trying to fetch data from gate.io. How can I get the server timestamp?

{
"label": "REQUEST_EXPIRED",
"message": "gap between request Timestamp and server time exceeds 60"
}

Also, I would like to know that from where I can get the gate.io
server time?

Is there any dedicated rest API endpoint available which will gives us server time stamp like other exchanges are providing?

Like provided by other wallet / exchange

https://www.okex.com/api/general/v3/time
https://api.binance.com/api/v3/time
https://api.kucoin.com/api/v1/timestamp
https://api.coinbase.com/v2/time
https://otc.ftx.com/api/time

I get an error message {“code“:-1,“message“:“Creating API V4 key and secret failed“} when creating an API v4 key.

I select all the permissions as "read only" and click save. Then input my fund password and google auth. After clicking the button, an error appears "Creating API v4 key and secret failed".

Hi,

We are seeing weird behaviour with /spot/batch_orders endpoint. Even though we are staying far below any documented rate limit (300/s or 900/s depending on the document), we are getting "TOO_MANY_REQUESTS" response.
A few notes: This only seems to happen when using batch_orders endpoints, and when it happens, most of the orders sent in the batch succeed, but some return this error.

This error is not mentioned anywhere in the documentation. Any advice or info on what kind of limit we are hitting? We are also wondering does sending 10 orders via batch_orders endpoint count as 1 or as 10 requests?

Thank you for any help!

Looking at the response from the v4 REST API interface for spot trades and comparing that to the same trades being returned by the v4 WebSocket interface.

It appears that the side value is inverted depending on which interface is used to retrieve the data -- for example, the side will be "buy" for the WebSocket interface, but "sell" when looking at the same trade using the REST API.

Here is an example:

v4 WebSocket:

{'time': 1646852753, 'channel': 'spot.trades', 'event': 'update', 'result': {'id': 2980886882, 'create_time': 1646852753, 'create_time_ms': '1646852753868.0', 'side': 'buy', 'currency_pair': 'BTC_USDT', 'amount': '0.0001', 'price': '42037.04'}}

v4 REST API:

{"id":"2980886882","create_time":"1646852754","create_time_ms":"1646852753868.677000","currency_pair":"BTC_USDT","side":"sell","amount":"0.0001","price":"42037.04"}

Note that the currency_pair, id, price and amount fields all match -- but the "side" field is inverted.

What is the proper way to interpret the side field?

When making trades via the v4 api, we pay 0.20% API fees. But when making a trade via the website, we pay only 0.125% on fees.

We would like to trade with the lower 0.125% fee via the API as well. Am I doing something wrong?

In the screenshot you can see the fees when trading on the website, and at the bottom you can see an API order in my trade history with a higher 0.20% fee.

Hello there,

I'd like to ask about fee rate fields in https://www.gate.io/docs/developers/apiv4/en/#contract. There are two fee rate fields, maker_fee_rate and taker_fee_rate. What is their semantics, are they just fees effective for current trade (identified by trade_id field)? Or are they in any way related to fees effective for my user account (https://www.gate.io/fee)?

Cheers,
L.

I am currently downloading data from: https://www.gate.io/developer/historical_quotes

However, there is no result comes out with my python code as following:

url = 'https://download.gatedata.org/futures_usdt/orderbooks/202108/BTC_USDT-2021080112.csv.gz'
response = requests.get(url, headers = headers)
pprint.pprint(response)

as the data is formatted in csv, in a short question, can I have a sample code/ method from gate.io on how to download such historical data systematically in python? or the only way is manually download?

Thank you.

This is not clear to consumers!
Please explain !
I have missed 4 months of life because of this shit system!
So I'm going to Red light your company as
Bad !

Was instructed by technical support to comment here regarding.
When using a 3commas bot on CRSP /USTD pair.
Base_order_messages Setting leveraged cross success.
Placing base order price 0.083 USTD size 20 (24 CSPR_USDT) Error occured during request market

Error placing base order: market could not validate your request could not validate your request.
When using a 3commas bot on CRSP /USTD pair.

Using API v4

Please help me resolve this as soon as possible I want to set up a leveraged bot.
Thanks Martin

we try to make withdrawal via API, but we accept an error
{
"AMOUNT": "50",
"ID": "TAdDuRdQQKQaoSrw5yktP6FjSzMNyr3iSs",
"Request_Method": "POST",
"Request_URL": "/withdrawals",
: "{could_not_parse_as_http,<<"HTTP/1.1 400\r\nDate: Wed, 02 Mar 2022 15:21:13 GMT\r\nContent-Type: application/json\r\nTransfer-Encoding: chunked\r\nConnection: keep-alive\r\nServer: openresty\r\nX-Frame-Options: SAMEORIGIN\r\nX-Powered-By: CF ()\r\nPragma: no-cache\r\nCache-Control: no-cache, must-revalidate\r\nSet-Cookie: login_notice_check=%2F; path=/; secure; HttpOnly\r\n\r\n7b\r\n{\"label\":\"INVALID_PARAM_VALUE\",\"message\":\"Error: only used addresses or verified addresses are allowed for api withdrawal\"}\r\n">>}",
api_return_http_code__": 0,
api_return_type_error__": "software",
api_return_type_tag__": "api_bad_answer",
"body":
"payload": {
"currency": "USDT",
"address": "TAdDuRdQQKQaoSrw5yktP6FjSzMNyr3iSs",
"amount": "50",
"memo": "",
"chain": "TRX"
},
"payload_string": "{"currency":"USDT","address":"TAdDuRdQQKQaoSrw5yktP6FjSzMNyr3iSs","amount":"50","memo":"","chain":"TRX"}",
"status": 200
}

Can you help us? We can`t work!

Hi, we receive 429 (rate limit) errors from the endpoints below, but we only do a few calls per minute. How is that possible?

api.gateio.ws/api/v4/wallet/deposits
api.gateio.ws/api/v4/wallet/withdrawals
api.gateio.ws/api/v4/spot/accounts
api.gateio.ws/api/v4/margin/currency_pairs

Hi!

I want to create a rust client based on your API schema but I can't find it anywhere.

Thanks

Problem

Endpoint: GET /spot/order_book (v4)

I am currently building an internal order book as described here. After receiving the first update event from the WebSocket, I am fetching the order book through the REST API.

Doing so, I occasionally observe the following unexpected behaviour:

orderbook event: 1639987999796 (spot.order_book_update['t'])
fetch orderbook
orderbook event: 1639987999861
orderbook event: 1639988000093
orderbook event: 1639988000160
orderbook event: 1639988000278
orderbook event: 1639988000341
orderbook event: 1639988000589
orderbook event: 1639988000675
orderbook event: 1639988000780
orderbook event: 1639988000878
received an answer. timestamp: 1639987998897 (response['current'])

How can the REST call timestamp (current) be smaller than the timestamp when the request was sent out? Upon investigation and implementing a workaround for this problem (fetching again), I discovered the following:

orderbook event: 1639992489593
fetch orderbook
orderbook event: 1639992489844
orderbook event: 1639992489946
orderbook event: 1639992490041
orderbook event: 1639992490243
orderbook event: 1639992490347
orderbook event: 1639992490435
orderbook event: 1639992490545
orderbook event: 1639992490644
orderbook event: 1639992490733
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992490925
orderbook event: 1639992491037
orderbook event: 1639992491136
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992491235
orderbook event: 1639992491341
orderbook event: 1639992491434
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992491506
orderbook event: 1639992491638
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992491845
orderbook event: 1639992491940
orderbook event: 1639992492035
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992492092
orderbook event: 1639992492333
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992492448
orderbook event: 1639992492545
orderbook event: 1639992492645
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992492728
orderbook event: 1639992492840
orderbook event: 1639992492934
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992493038
orderbook event: 1639992493099
orderbook event: 1639992493242
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992493345
orderbook event: 1639992493437
orderbook event: 1639992493547
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992493635
orderbook event: 1639992493830
received an answer. timestamp: 1639992489005
fetch again
orderbook event: 1639992494041
orderbook event: 1639992494136
received an answer. timestamp: 1639992494303

This makes me wonder if there is some caching involved on your side? If so, it is not documented yet. If not, do you have any explanation for why this occurs? There is definitely no caching on my side.

Please let me know if you need additional information.

Hello there,

Regarding the perpetual/delivery contracts provided via REST API, Contract/DeliveryContract (https://www.gate.io/docs/developers/apiv4/en/#contract): there is "order_size_min" for minimum order size. Is there any restriction on minimum order size increments (similar to "order_price_round" for minimum order price increments)? That is e.g. if "order_size_min" is X, is it possible to make orders of size "X+1", "X+2", ... till "order_size_max"? Or is there any other minimum increment "Y" (other than 1), so order size would need to be "X + n * Y"?

Thanks!