CFDs are complex instruments and come with a high risk of losing money rapidly due to leverage. 64 % of retail investor accounts lose money when trading CFDs with this provider. You should consider whether you understand how CFDs work and whether you can afford to take the high risk of losing your money.

Swagger different from API implementation

Hi all,

first of all, great work! Transparency is something really, really valuable in markets and you are trying to put it on the table.

Well, I have started tinkering with the API and I have stumbled upon some problems on python.


API requested data is not compliant with swagger.json specified in the store.


First of, I would like to do some ML via python.

Hence, I decided to give it a try to bravado. As I have understood, bravado is able to extract from Darwinex API swagger.json file all the structure of the API operations. This way, we avoid to manually type all such urls ourselves, leading to way more reliable and up-to-date code.

While doing so, and error popped up to me while trying to retrieve marketcorrelation

Failed validating 'type' in schema['items']['items']:
    {'items': {'type': 'string'}, 'type': 'array'}

On instance[0][0]:

please, take a look to the code below to reproduce this issue:

Code snippet

  • credentials.access_token: is your Oauth2.0 access_token.
from bravado.client import SwaggerClient
import httplib2
headers = {
    "Accept": "application/json",
    "Authorization": "Bearer %s" % credentials.access_token,
request_options = {'headers' : headers}
client = SwaggerClient.from_url(ENDPOINT)
# Next 3 are OK!
client.products.get_products_productName_dxscore(productName='LVS.4.20', _request_options=request_options).response().incoming_response.json()
client.products.get_products_productName_status(productName='LVS.4.20', _request_options=request_options).response().incoming_response.json()
client.products.get_products_productName_scores(productName='LVS.4.20', _request_options=request_options).response().incoming_response.json()
# Next 3 are NOK! Maybe #/definitions/HistoryResponseDTO is wrong?
client.products.get_products_productName_history_riskadjustment(productName='LVS.4.20', _request_options=request_options).response().incoming_response.json()
client.products.get_products_productName_history_riskstability(productName='LVS.4.20', _request_options=request_options).response().incoming_response.json()
client.products.get_products_productName_history_marketcorrelation(productName='LVS.4.20', _request_options=request_options).response().incoming_response.json()

should you need pip-freezing my env do not hesitate to ask.


Additionally, via python requests module, I’ve seen that there is inconsistency in historic data. There are times in which there are no arrays in payload data which should have array data (it could be empty to keep consistency).

Thanks for everything!


I tested the posted code, but using Direct Access Token, getting the same type of error.

I tested other methods and all those that have schema $ ref "# / definitions / HistoryResponseDTO, returns the same error.

1 Like

Hi @gilsoriano,

Thanks for your message!

I have been able to reproduce the issue here with that code.

The history data requests are a bit less json structured data to avoid boilerplate over the requests and minimize the size of the data being transferred. In the case of the riskadjustment, for instance, the data being sent has the following format:
- item[0] -> (long) Millis
- item[1] -> (double) D-Periods
- item[2][0] -> (double) Leverage target of day (deprecated)
- item[2][1] -> (double) VaR of day
- item[2][$position][0] -> (long) Open time of position
- item[2][$position][1] -> (long) Duration of position
- item[2][$position][2] -> (double) D-Leverage of position
- item[2][$position][3] -> (double) VaR adjustment of position
- item[2][$position][4] -> (integer) Number of open trades
- item[2][$position][5] -> (double) Return of position
- item[2][$position][6] -> (double) Leverage target of position

In most of the cases, the data has arrays with different kind of objects, including other arrays itself. It could be good to know what definition is expecting the “bravado” client for these objects… in swagger 2.0. With OpenAPI 3.0 we could specify that all the objects have a type “anyOf” defining different types for each field.

Otherwise, we could try to map these objects to a more JSON-structured object in a new version of the API with field names up to the second level.


1 Like

I forgot to mention before… Current Beta access is restricted to 20 calls / minute per application client, or some more calls / minute to the shared application client used by everyone using direct access token. Therefore, there might be calls being blocked due to the limit. Perhaps, the times in which there is nothing in the payload data might be happening due to this limit.

1 Like