@blackforce/deribit_api v2.0.0

deribit_api

DeribitApi - JavaScript client for deribit_api #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 This SDK is automatically generated by the OpenAPI Generator project:

• API version: 2.0.0
• Package version: 2.0.0
• Build package: org.openapitools.codegen.languages.JavascriptClientCodegen

Installation

For Node.js

npm

To publish the library as a npm, please follow the procedure in "Publishing npm packages".

Then install it via:

npm install deribit_api --save

Finaly, you need to build the module:

npm run build

Local development

To use the library locally without publishing to a remote npm registry, first install the dependencies by changing into the directory containing package.json (and this README). Let's call this JAVASCRIPT_CLIENT_DIR. Then run:

npm install

Next, link it globally in npm with the following, also from JAVASCRIPT_CLIENT_DIR:

npm link

To use the link you just defined in your project, switch to the directory you want to use your deribit_api from, and run:

npm link /path/to/<JAVASCRIPT_CLIENT_DIR>

Finaly, you need to build the module:

npm run build

git

If the library is hosted at a git repository, e.g.https://github.com/GIT_USER_ID/GIT_REPO_ID then install it via:

    npm install GIT_USER_ID/GIT_REPO_ID --save

For browser

The library also works in the browser environment via npm and browserify. After following the above steps with Node.js and installing browserify with npm install -g browserify, perform the following (assuming main.js is your entry file):

browserify main.js > bundle.js

Then include bundle.js in the HTML pages.

Webpack Configuration

Using Webpack you may encounter the following error: "Module not found: Error: Cannot resolve module", most certainly you should disable AMD loader. Add/merge the following section to your webpack config:

module: {
  rules: [
    {
      parser: {
        amd: false
      }
    }
  ]
}

Getting Started

Please follow the installation instruction and execute the following JS code:

var DeribitApi = require('deribit_api');

var defaultClient = DeribitApi.ApiClient.instance;
// Configure Bearer (Auth. Token) access token for authorization: bearerAuth
var bearerAuth = defaultClient.authentications['bearerAuth'];
bearerAuth.accessToken = "YOUR ACCESS TOKEN"

var api = new DeribitApi.AccountManagementApi()
var sid = 56; // {Number} The user id for the subaccount
var name = newUserName; // {String} The new user name
var callback = function(error, data, response) {
  if (error) {
    console.error(error);
  } else {
    console.log('API called successfully. Returned data: ' + data);
  }
};
api.privateChangeSubaccountNameGet(sid, name, callback);

Documentation for API Endpoints

All URIs are relative to https://www.deribit.com/api/v2

Documentation for Models

• DeribitApi.AddressBookItem
• DeribitApi.BookSummary
• DeribitApi.Currency
• DeribitApi.CurrencyPortfolio
• DeribitApi.CurrencyWithdrawalPriorities
• DeribitApi.Deposit
• DeribitApi.Instrument
• DeribitApi.KeyNumberPair
• DeribitApi.Order
• DeribitApi.OrderIdInitialMarginPair
• DeribitApi.Portfolio
• DeribitApi.PortfolioEth
• DeribitApi.Position
• DeribitApi.PublicTrade
• DeribitApi.Settlement
• DeribitApi.TradesVolumes
• DeribitApi.TransferItem
• DeribitApi.Types
• DeribitApi.UserTrade
• DeribitApi.Withdrawal

Documentation for Authorization

bearerAuth

• Type: Bearer authentication (Auth. Token)