C++ API client

#Overview Deribit provides three different interfaces to access the API: * JSON-RPC over Websocket * JSON-RPC over HTTP * FIX (Financial Information eXchange) With the API Console you can use and test the JSON-RPC API, both via HTTP and via Websocket. To visit the API console, go to Account > API tab > API Console tab. ##Naming Deribit tradeable assets or instruments use the following system of naming: |Kind|Examples|Template|Comments| |----|--------|--------|--------| |Future|BTC-25MAR16, BTC-5AUG16|BTC-DMMMYY|BTC is currency, DMMMYY is expiration date, D stands for day of month (1 or 2 digits), MMM - month (3 first letters in English), YY stands for year.| |Perpetual|BTC-PERPETUAL ||Perpetual contract for currency BTC.| |Option|BTC-25MAR16-420-C, BTC-5AUG16-580-P|BTC-DMMMYY-STRIKE-K|STRIKE is option strike price in USD. Template K is option kind: C for call options or P for put options.| # JSON-RPC JSON-RPC is a light-weight remote procedure call (RPC) protocol. The JSON-RPC specification defines the data structures that are used for the messages that are exchanged between client and server, as well as the rules around their processing. JSON-RPC uses JSON (RFC 4627) as data format. JSON-RPC is transport agnostic: it does not specify which transport mechanism must be used. The Deribit API supports both Websocket (preferred) and HTTP (with limitations: subscriptions are not supported over HTTP). ## Request messages > An example of a request message: json { \"jsonrpc\": \"2.0\", \"id\": 8066, \"method\": \"public/ticker\", \"params\": { \"instrument\": \"BTC-24AUG18-6500-P\" } } According to the JSON-RPC sepcification the requests must be JSON objects with the following fields. |Name|Type|Description| |----|----|-----------| |jsonrpc|string|The version of the JSON-RPC spec: "2.0"| |id|integer or string|An identifier of the request. If it is included, then the response will contain the same identifier| |method|string|The method to be invoked| |params|object|The parameters values for the method. The field names must match with the expected parameter names. The parameters that are expected are described in the documentation for the methods, below.| <aside class="warning"> The JSON-RPC specification describes two features that are currently not supported by the API:

• Specification of parameter values by position
• Batch requests

## Response messages > An example of a response message: json { \"jsonrpc\": \"2.0\", \"id\": 5239, \"testnet\": false, \"result\": [ { \"currency\": \"BTC\", \"currencyLong\": \"Bitcoin\", \"minConfirmation\": 2, \"txFee\": 0.0006, \"isActive\": true, \"coinType\": \"BITCOIN\", \"baseAddress\": null } ], \"usIn\": 1535043730126248, \"usOut\": 1535043730126250, \"usDiff\": 2 } The JSON-RPC API always responds with a JSON object with the following fields. |Name|Type|Description| |----|----|-----------| |id|integer|This is the same id that was sent in the request.| |result|any|If successful, the result of the API call. The format for the result is described with each method.| |error|error object|Only present if there was an error invoking the method. The error object is described below.| |testnet|boolean|Indicates whether the API in use is actually the test API. false for production server, true for test server.| |usIn|integer|The timestamp when the requests was received (microseconds since the Unix epoch)| |usOut|integer|The timestamp when the response was sent (microseconds since the Unix epoch)| |usDiff|integer|The number of microseconds that was spent handling the request| <aside class="notice"> The fields testnet, usIn, usOut and usDiff are not part of the JSON-RPC standard.

In order not to clutter the examples they will generally be omitted from the example code.

> An example of a response with an error: json { \"jsonrpc\": \"2.0\", \"id\": 8163, \"error\": { \"code\": 11050, \"message\": \"bad_request\" }, \"testnet\": false, \"usIn\": 1535037392434763, \"usOut\": 1535037392448119, \"usDiff\": 13356 } In case of an error the response message will contain the error field, with as value an object with the following with the following fields: |Name|Type|Description |----|----|-----------| |code|integer|A number that indicates the kind of error.| |message|string|A short description that indicates the kind of error.| |data|any|Additional data about the error. This field may be omitted.| ## Notifications > An example of a notification: json { \"jsonrpc\": \"2.0\", \"method\": \"subscription\", \"params\": { \"channel\": \"deribit_price_index.btc_usd\", \"data\": { \"timestamp\": 1535098298227, \"price\": 6521.17, \"index_name\": \"btc_usd\" } } } API users can subscribe to certain types of notifications. This means that they will receive JSON-RPC notification-messages from the server when certain events occur, such as changes to the index price or changes to the order book for a certain instrument. The API methods public/subscribe and private/subscribe are used to set up a subscription. Since HTTP does not support the sending of messages from server to client, these methods are only availble when using the Websocket transport mechanism. At the moment of subscription a "channel" must be specified. The channel determines the type of events that will be received. See Subscriptions for more details about the channels. In accordance with the JSON-RPC specification, the format of a notification is that of a request message without an id field. The value of the method field will always be "subscription". The params field will always be an object with 2 members: channel and data. The value of the channel member is the name of the channel (a string). The value of the data member is an object that contains data that is specific for the channel. ## Authentication > An example of a JSON request with token: json { \"id\": 5647, \"method\": \"private/get_subaccounts\", \"params\": { \"access_token\": \"67SVutDoVZSzkUStHSuk51WntMNBJ5mh5DYZhwzpiqDF\" } } The API consists of public and private methods. The public methods do not require authentication. The private methods use OAuth 2.0 authentication. This means that a valid OAuth access token must be included in the request, which can get achived by calling method public/auth. When the token was assigned to the user, it should be passed along, with other request parameters, back to the server: |Connection type|Access token placement |----|-----------| |Websocket|Inside request JSON parameters, as an access_token field| |HTTP (REST)|Header Authorization: bearer ```Token``` value| ### Additional authorization method - basic user credentials <span style="color:red"> ! Not recommended - however, it could be useful for quick testing API
Every private method could be accessed by providing, inside HTTP Authorization: Basic XXX header, values with user ClientId and assigned ClientSecret (both values can be found on the API page on the Deribit website) encoded with Base64: Authorization: Basic BASE64(ClientId + : + ClientSecret) ### Additional authorization method - Deribit signature credentials The Derbit service provides dedicated authorization method, which harness user generated signature to increase security level for passing request data. Generated value is passed inside Authorization header, coded as: Authorization: deri-hmac-sha256 id=ClientId,ts=Timestamp,sig=Signature,nonce=Nonce where: |Deribit credential|Description |----|-----------| |ClientId|Can be found on the API page on the Deribit website| |Timestamp|Time when the request was generated - given as miliseconds. It's valid for 60 seconds since generation, after that time any request with an old timestamp will be rejected.| |Signature|Value for signature calculated as described below | |Nonce|Single usage, user generated initialization vector for the server token| The signature is generated by the following formula: Signature = HEX_STRING( HMAC-SHA256( ClientSecret, StringToSign ) );
StringToSign = Timestamp + "\n" + Nonce + "\n" + RequestData;
RequestData = UPPERCASE(HTTP_METHOD()) + "\n" + URI() + "\n" + RequestBody + "\n";
e.g. (using shell with openssl tool):     ClientId=AAAAAAAAAAA
    ClientSecret=ABCD
    Timestamp=$( date +%s000 )
    Nonce=$( cat /dev/urandom | tr -dc 'a-z0-9' | head -c8 )
    URI="/api/v2/private/get_account_summary?currency=BTC"
    HttpMethod=GET
    Body=""

    Signature=$( echo -ne "${Timestamp}\n${Nonce}\n${HttpMethod}\n${URI}\n${Body}\n" | openssl sha256 -r -hmac "$ClientSecret" | cut -f1 -d' ' )

    echo $Signature

    shell output> ea40d5e5e4fae235ab22b61da98121fbf4acdc06db03d632e23c66bcccb90d2c (WARNING: Exact value depends on current timestamp and client credentials

    curl -s -X ${HttpMethod} -H "Authorization: deri-hmac-sha256 id=${ClientId},ts=${Timestamp},nonce=${Nonce},sig=${Signature}" "https://www.deribit.com${URI}\"

### Additional authorization method - signature credentials (WebSocket API) When connecting through Websocket, user can request for authorization using client_credential method, which requires providing following parameters (as a part of JSON request): |JSON parameter|Description |----|-----------| |grant_type|Must be client_signature| |client_id|Can be found on the API page on the Deribit website| |timestamp|Time when the request was generated - given as miliseconds. It's valid for 60 seconds since generation, after that time any request with an old timestamp will be rejected.| |signature|Value for signature calculated as described below | |nonce|Single usage, user generated initialization vector for the server token| |data|Optional field, which contains any user specific value| The signature is generated by the following formula: StringToSign = Timestamp + "\n" + Nonce + "\n" + Data;
Signature = HEX_STRING( HMAC-SHA256( ClientSecret, StringToSign ) );
e.g. (using shell with openssl tool):     ClientId=AAAAAAAAAAA
    ClientSecret=ABCD
    Timestamp=$( date +%s000 ) # e.g. 1554883365000
    Nonce=$( cat /dev/urandom | tr -dc 'a-z0-9' | head -c8 ) # e.g. fdbmmz79
    Data=""

    Signature=$( echo -ne "${Timestamp}\n${Nonce}\n${Data}\n" | openssl sha256 -r -hmac "$ClientSecret" | cut -f1 -d' ' )

    echo $Signature

    shell output> e20c9cd5639d41f8bbc88f4d699c4baf94a4f0ee320e9a116b72743c449eb994 (WARNING: Exact value depends on current timestamp and client credentials

You can also check the signature value using some online tools like, e.g: https://codebeautify.org/hmac-generator (but don't forget about adding newline after each part of the hashed text and remember that you should use it only with your test credentials). Here's a sample JSON request created using the values from the example above: {
  "jsonrpc" : "2.0",
  "id" : 9929,
  "method" : "public/auth",
  "params" :
  {
    "grant_type" : "client_signature",
    "client_id" : "AAAAAAAAAAA",
    "timestamp": "1554883365000",
    "nonce": "fdbmmz79",
    "data": "",
    "signature" : "e20c9cd5639d41f8bbc88f4d699c4baf94a4f0ee320e9a116b72743c449eb994"
  }
}
### Access scope When asking for access token user can provide the required access level (called scope) which defines what type of functionality he/she wants to use, and whether requests are only going to check for some data or also to update them. Scopes are required and checked for private methods, so if you plan to use only public information you can stay with values assigned by default. |Scope|Description |----|-----------| |account:read|Access to account methods - read only data| |account:read_write|Access to account methods - allows to manage account settings, add subaccounts, etc.| |trade:read|Access to trade methods - read only data| |trade:read_write|Access to trade methods - required to create and modify orders| |wallet:read|Access to wallet methods - read only data| |wallet:read_write|Access to wallet methods - allows to withdraw, generate new deposit address, etc.| |wallet:none, account:none, trade:none|Blocked access to specified functionality| <span style="color:red">NOTICE: Depending on choosing an authentication method (grant type) some scopes could be narrowed by the server. e.g. when grant_type = client_credentials and scope = wallet:read_write it's modified by the server as scope = wallet:read" ## JSON-RPC over websocket Websocket is the prefered transport mechanism for the JSON-RPC API, because it is faster and because it can support subscriptions and cancel on disconnect. The code examples that can be found next to each of the methods show how websockets can be used from Python or Javascript/node.js. ## JSON-RPC over HTTP Besides websockets it is also possible to use the API via HTTP. The code examples for 'shell' show how this can be done using curl. Note that subscriptions and cancel on disconnect are not supported via HTTP. #Methods

Overview

This API client was generated by the OpenAPI Generator project. By using the OpenAPI spec from a remote server, you can easily generate an API client.

• API version: 2.0.0

• Package version:

• Build package: org.openapitools.codegen.languages.CppRestSdkClientCodegen

• API namespace: org.openapitools.client.api

• Model namespace: org.openapitools.client.model

Installation

Prerequisites

Install cpprestsdk.

• Windows: vcpkg install cpprestsdk cpprestsdk:x64-windows boost-uuid boost-uuid:x64-windows
• Mac: brew install cpprestsdk
• Linux: sudo apt-get install libcpprest-dev

Build

cmake -DCPPREST_ROOT=/usr -DCMAKE_CXX_FLAGS="-I/usr/local/opt/openssl/include" -DCMAKE_MODULE_LINKER_FLAGS="-L/usr/local/opt/openssl/lib"
make

Build on Windows with Visual Studio (VS2017)

• Right click on folder containing source code
• Select 'Open in visual studio'
• Once visual studio opens, CMake should show up in top menu bar.
• Select CMake > Build All.

*Note: If the CMake menu item doesn't show up in Visual Studio, CMake for Visual Studio must be installed. In this case, open the 'Visual Studio Installer' application. Select 'modify' Visual Studio 2017. Make sure 'Desktop Development with C++' is installed, and specifically that 'Visual C++ tools for CMake' is selected in the 'Installation Details' section.

Also be sure to review the CMakeLists.txt file. Edits are likely required.*

Author