1. About this Document
This document is a high-level specification for the Devexperts REST API. The API is to provide a set of functions to enable trading for any interested party.
1.1. Revision History
Table shows updates of this document:
| Revision Date | Version | Change Details |
|---|---|---|
27-March-2017 |
13.9 |
Updated next section: List Orders. |
05-June-2017 |
13.12 |
1) Cancel and modify order resources now support order groups. |
14-June-2017 |
13.13 |
ContingencyType PNC renamed to IF-THEN and PNCOCO removed in Order Group Request. |
28-December-2017 |
13.29 |
For List Orders request added transaction-from and transaction-to parameters.
For Historic Order List response added parameter nextPageTransactionTime. |
22-January-2018 |
13.32 |
Flag isPositionBased was added to Account Details. |
14-September-2018 |
28.3 |
Field lastQuantity was added to Execution. |
11-October-2018 |
28.5 |
Added quantityNotional field to Position and Position Metrics. Added filledQuantityNotional, lastQuantityNotional fields to Execution. |
12-October-2018 |
28.6 |
Update information about signs of quantity notional fields in Position Metrics and Execution. |
26-June-2020 |
41 |
Added REBATE and EX_DIVIDEND transfer types support for Cash Transaction and List Cash Transfers |
23-Feb-2022 |
57 |
Field margin in Account Metrics renamed to maintenanceMargin, a new field initialMargin was added to Account Metrics. Field margin in Position Metrics renamed to initialMargin, a new field maintenanceMargin was added to Position Metrics |
28-Feb-2023 |
212 |
Added possible value STOP_LIMIT in "type" field of Order |
29-August-2023 |
216 |
Added SERVICE_CHARGE transfer type support for Cash Transaction and List Cash Transfers |
26-October-2023 |
217 |
Added DIVIDEND, EXPIRATION, DELISTING, SPIN_OFF, RENAME, MERGER_ACQUISITION, SPLIT, EXERCISE, POSITION_UPDATE transfer types support for Cash Transaction and List Cash Transfers |
14-November-2023 |
218 |
Added support of TRAILING_STOP, TRAILING_STOP_LIMIT order types. Added *stopPriceOffset" and "limitPriceOffset" to Order, Single Order Request, Multileg Order Request |
20-November-2023 |
218 |
Section 'Rate Limits & Throttling' was updated with information about rate limits for login/'get data'/trading requests. |
20-November-2023 |
218 |
Updated the result of the request to show historical orders (List Orders). The nextPageTransactionTime field is provided as part of the response in case when count of orders is greater than the limit parameter used by the client and this limit is less than the default value predefined in the historic.orders.max.count property in the server side. The nextPageTransactionTime field is provided as well in case when the page and page-size parameters are used. |
18-March-2024 |
XT-45 |
Added field futuresMarginRequirements for futures margin requirements to Instrument. |
05-June-2024 |
XT-73 |
Sections 'Account Metrics', 'List Account Portfolio', 'List Open Positions' was updated with information about possible errors. |
18-June-2024 |
XT-78 |
Added intermediateStopPrice and intermediateLimitPrice fields to Order. |
30-jun-2025 |
XT-254 |
Improved Ping API and Basic Authentication descriptions |
18-August-2025 |
XT-278 |
Cash Transaction and Cash Transfer information has been extended with the new field createdTime that stores the time of a creating cash transaction/transfer request. It could take some time till actual transaction happens, exact transaction time is shown in transactionTime field. |
05-December-2025 |
XT-6643 |
Added API for account flatten |
2. API Principles
HTTP REST API is characterized by the "uniform interface" principle, where operations are modeled as a set of universal actions over resources. In this model, resources are actual business objects (e.g. orders, positions, instruments). Possible set of actions is limited by a standard set of HTTP methods also known as "verbs" (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html). Resources are identified by unique URIs. Operations such as GET are invoked on resources such as /order/123.
2.1. Supported methods
DX REST API supports the following HTTP methods / verbs:
GET |
For retrieving data from the system; this method doesn’t change system in any way and is considered idempotent. Responses for this method can be cached to improve performance. See also Conditional Requests & Updates. |
POST |
For creating new resources or doing actions in the system; this method changes system state and cannot be repeated without undesired side effects; method is considered not idempotent. Responses for this method shall never be cached. |
PUT |
For updating complete state of a resource; all new and old resource details are transmitted. This method changes system state and is idempotent. It can be repeated several times safely with predictable results (new resource state). Responses for this method shall never be cached. See also Conditional Requests & Updates. |
DELETE |
For deleting or discontinuing resources. This method changes system state and is idempotent. It can be repeated several times safely with the predictable results (deleted resource). Responses for this method shall never be cached. See also Conditional Requests & Updates. |
REST-style architectures consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of representations of resources. A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.
The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered in transition. The representation of each application state contains links that may be used the next time the client chooses to initiate a new state-transition.
See http://en.wikipedia.org/wiki/Representational_state_transfer for details on REST architectural paradigm.
DX REST API is built on top of HTTP/1.1 which is a newer spec than HTTP/1.0.
2.2. Accompanying APIs
The REST API is a synchronous request-response API. As the API is based on HTTP protocol, no realtime notifications are provided. Push notifications are described in a separate document.
With that, REST API permits implementing fully functional "non-realtime" applications which can poll for updated information. REST API doesn’t rely on any other API.
2.3. Target Clients
DX REST API provides functionality for:
-
Non-disclosed integration when there is a single source of orders which uses the API to trade on behalf of multiple users who are not visible to Devexperts platform. All the trades a partner makes are allocated on a single account in the system.
-
"Gateway" disclosed integration when there is a single source of orders which uses the API to trade on behalf of multiple users who are visible to the platform. All the trades a partner makes are allocated on a multiple accounts in the system; there is a record for each account. But the orders and information flows via a single connection; clients are not connected to the system directly but are connected to partner’s system.
-
"Direct" disclosed integration when partner’s users are connected directly to Devexperts'-built backend; there is a separate connection for each user. The system has a record for each account.
2.4. Supported Representations & MIME Types
The following representation and request formats are supported by the REST API:
-
XML (as de-facto communication standard).
-
JSON (as a more lightweight and browser-friendly standard).
Custom XML and JSON schemas are used. The following MIME types are supported:
-
application/xml – for XML format
-
application/json – for JSON format
JSON is the default representation and request format. If the Accept header sent by the client prohibits both XML and JSON format, the server responds with 406 Not Acceptable status code. See also Error Handling.
In HTTP, preferences for response representation are indicated by the client via the Accept header. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html for the header definition.
The server, based on its capabilities, evaluates client preferences and identifies the representation to return.
The API uses the following standard algorithm for representation negotiation:
-
Receive the Accept header, parse it
-
If there is no Accept header, return representation in JSON format
-
Sort preferred representation types by the "q" parameter in descending order
-
From that list select the first media type the server supports
-
If the server doesn’t support any representation accepted by the client, respond with 406 Not Acceptable status code. See also Error Handling.
If the Accept header was used to determine representation format (client indicated several supported formats or didn’t specify any), the server shall include the Vary header with the value of "Accept".
Accept: application/atom+xml;q=1.0, application/xml;q=0.6, text/html;q=0.8, */*
For this header, the server:
-
Parses the Accept header
-
Sorts preferred representations by the "q" parameter:
-
application/atom+xml
-
text/html
-
application/xml
-
any media type (*/*)
-
-
Takes the first supported media type which is application/xml
See also API Versioning.
2.5. Supported Encodings
DX REST API supports only the UTF-8 encoding.
In HTTP, client can indicate preferences for the desired encoding using the Accept-Charset header. This is not supported in dx REST API and UTF-8 is always be returned regardless of presence/absence and actual value of the Accept-Charset header.
The server does not include the Vary header with the "Accept-Charset" value.
2.6. Supported Compressions
DX REST API supports the standard HTTP "gzip" and "deflate" compression methods. See http://en.wikipedia.org/wiki/HTTP_compression.
Client’s preference is communicated via the Accept-Encoding header as a plain list. The server selects any of the supported compression method supported by the client. If client doesn’t support any compression methods, data shall not be compressed.
If Accept-Encoding header was used to determine a compression method, the server includes the Vary header with a value of "Accept-Encoding".
2.7. Error Handling
DX REST API relies on the standard HTTP status codes for communicating errors. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Codes in the range of 400-499 indicate an error on client side which can be fixed by amending request and re-trying. Codes in the range of 500-599 indicate a server-side error.
DX REST API does not use any custom status codes. Each error is be reported via the status code; response body is to include an internal error code (if applicable) as well as error description.
| Status code | Error | Additional information |
|---|---|---|
400 Bad Request |
Client sent a malformed request, such as missing Host header or semantically incorrect request. |
The client should not repeat the request without modifications |
401 Unauthorized |
Client is not authorized in the system. See Authentication. |
|
403 Forbidden |
Client submitted a request without the required condition. See Conditional Requests & Updates |
For security reasons, 403 Forbidden status code is not used to indicate resources for which the client has no permissions. In this case 404 status code is used. |
404 Not Found |
Either the resource does not exist or client is not permitted to access the resource. |
|
405 Method Not Allowed |
HTTP method specified in request is not permitted for this resource |
Response must contain an Allow header with the list of supported methods. |
406 Not Acceptable |
REST API doesn’t support the specified representation format. |
|
409 Conflict |
REST API understood the request but there are semantic issues with the request and the request could not be validated |
Used to indicate application-level errors, see Application-Level Errors. |
412 Precondition Failed |
Conditional request failed. |
|
413 Request Entity Too Large |
REST API refuses to process a request because request size is greater than a pre-defined threshold. |
Security measure to avoid DDoS attacks. See Request Length Limit. |
415 Unsupported Media Type |
Client sends the message body in a format that the server does not understand (neither in application/xml nor in application/json format). |
|
429 Too Many Requests |
The user sent too many request in a given amount of time. See API Throttling |
|
500 Internal Server Error |
An unexpected error occurred on server. Request is not processed. |
2.8. Application-Level Errors
Application level errors is reported in a response as special "error" objects containing the following data:
| Code | Error code; distinct for different distinct errors |
|---|---|
Description |
Human-readable description of the issue (in English; subject to change without changes in API version) |
2.9. Common Errors
The following errors may be triggered by any resource of the API:
-
Request comes from the non-authenticated client
Status code Error code Description 401 Unauthorized
1
Authorization required
-
Malformed HMAC signature (HMAC authentication failed due to malformed HMAC signature header. See HMAC Authentication).
Status code Error code Description 400 Bad Request
11
Malformed HMAC signature
-
HMAC signature too old (more than a permitted amount of time passed since the request was created. See HMAC Authentication).
Status code Error code Description 401 Unauthorized
12
HMAC signature too old
-
HMAC signature mismatch (HMAC signature check failed; authentication failed. See HMAC Authentication).
Status code Error code Description 401 Unauthorized
13
HMAC signature mismatch
2.10. API Versioning
The Notification API attempts (if possible) to maintain backward compatibility with the clients provided the following:
-
Clients ignore the data they do not understand
-
Clients only use the data they need
For example, in case of XML representation, clients must make sure they do not couple their logic with current XML representation in such a way that adding new fields causes their application to malfunction. This allows adding new data to resources without breaking clients.
If data is removed or data meaning is changed, a new notification API version is introduced. Switch between different versions is based on the URI of the API (e.g. http://host/api/v1 for version 1 and http://host/api/v2 for version 2).
API versioning supports only major integer versions such as 1,2,3 etc. With the API, there is no notion of minor releases.
| Change | New Version Released? |
|---|---|
Addition of a new data field to data representation |
No |
Changing the logical meaning of a field |
Yes |
Removing a field |
Yes |
Changing the default representation, currency units etc. |
Yes |
Addition of new independent requests |
No |
New business rules and/or application flow |
Yes |
New default values for optional request parameters or fields |
Yes |
2.11. Conditional Requests & Updates
dx REST API relies on standard HTTP conditional update and request mechanism (http://en.wikipedia.org/wiki/HTTP_ETag) to ensure that:
-
No update is missed and client is always updating the latest resource version (conditional PUT and DELETE requests).
-
The client already has the latest version of the resource and there is no need to re-compute the representation again (conditional GET requests).
DX REST API does not use the If-Modified-Since/Last-Modified headers
since ETag/If-Match/If-None-Match provide more fine-grained control and
do not suffer from time precision issues.
Conditional GETs
Some GET requests to the REST API (except for collection queries) support conditions with the ETag headers according to the following algorithm:
-
Client makes a GET request to a resource without the
If-None-Matchheader. -
Server always returns a representation of the resource with an
ETagheader set. TheETagheader uniquely and transparently identifies the version of the resource. -
If a resource is updated, its version is incremented and previous
ETagsare no longer valid. -
Client makes a GET request to a resource specifying the
If-None-Matchheader with the value of previously receivedETag. -
If
ETagmatches the current version on the server, the server responds with304 Not Modifiedstatus code and empty body. The server includes theETagheader to the response. -
If
ETagdoesn’t match the current version on the server, the server responds with a new resource representation and includes the newETagheader in the response.
This allows for effective caching on client side and reduces traffic and server resources consumption.
Conditional PUTs and DELETEs
All PUT and DELETE requests to the REST API must contain ETag headers
according to the following algorithm:
-
Client makes a GET request to a resource without the
If-None-Matchheader. -
Server always returns a representation of the resource with an
ETagheader set. TheETagheader shall uniquely identify the version of the resource. -
If a resource is updated, its version is incremented and previous
ETagsare no longer valid. -
Client makes a PUT or DELETE request to a resource specifying the
If-Matchheader with the value of previously receivedETag. -
If
ETagmatches the current version on the server, the server proceeds with the request. -
If
ETagdoesn’t match the current version on the server, the server responds with412 Precondition Failedstatus. Client is expected to retrieve the latest resource version and retry the request. -
If the client doesn’t submit the
If-Matchheader, status code of403 Forbiddenis returned along with the error details.
This prohibits "stale update" problem when there are several simultaneous updates for the same resource and one update overrides the other.
2.12. Caching
Relying on HTTP, DX REST API supports standard HTTP caching. Where appropriate, REST API permits caching by setting caching policy and expiration headers. Some of the resources are never cached and this is indicated explicitly by setting corresponding headers. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html for Cache-Control header specification. See also http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
REST API only permits caching responses to GET requests. All the other HTTP methods are not cached and Cache-Control headers are not sent for them.
The following header is included to enable caching:
| Header | Values | Description |
|---|---|---|
Cache-Control |
|
Max-age should be set to the amount of time the value is considered fresh. Caches and clients are expected to renew values after this interval of time. Private indicates that the response shall not be cached in intermediate caches, but only on the client. This is the default in case different representations are served to different users. Public indicates that all the caches can serve the response. Must-revalidate indicates that caches shall revalidate the stale value with the server. |
Cache-Control: max-age=3600,public,must-revalidate
Enable caching of this response for an hour; permit caching in all caches; caches must revalidate the stale value with the server.
The following headers are included to disable caching:
| Header | Values | Description |
|---|---|---|
Cache-Control |
|
These directives effectively disable caching on all levels. |
Cache-Control: no-cache,no-store
Disable caching of this response.
2.13. Entity Versioning
Notification API (together with the REST API) supports the notion of entity versions. Each business entity (such an account) has a version which is a number that increases monotonically with any changes. It is possible to find out the order of updates by comparing versions: most recent entity’s version will be greater.
3. Data Types and Formats
3.1. Numbers
The API expects (and returns) numeric values formatted according to W3C XML schema rules for “double” and “integer” types (see double and integer). The format is portable and country-independent. Dot (“.”) is used as a decimal separator; other separators (such as thousands) are not supported. Samples are: 123.456, +1234.456, -1234.456, -.456, 123, -1E4, +INF.
3.2. Booleans
Boolean values are encoded as "true" or "false" strings. Absence of value (where appropriate) is interpreted as "false".
3.3. Times and Dates
All times and dates in the API are encoded according to RFC 3339. This is a standard convention which is supported by most of the programming languages and frameworks.
RFC 3339-formatted dates and times have the following characteristics:
-
This format is human readable.
-
Two values can be compared using lexicographical comparison (i.e. sort values as strings)
Times and dates are either in UTC coordinated time or include timezone offset information.
The following formats are supported:
| Format Sample | When used |
|---|---|
2013-01-24T23:05:08.52Z |
UTC timestamp with milliseconds precision used everywhere when a timestamp is expected. |
2013-01-24Z |
UTC date, used everywhere when a date is expected. |
Monday, 23:00:00Z |
UTC week date, used everywhere when a week-relative date is expected. |
23:05:08.52Z |
UTC time |
01:05:08 |
Time interval |
1464264688310 |
UNIX milliseconds since epoch |
3.4. Currencies
Currency information is encoded according to ISO 4217. This is an international standard which specifies three-letter currency codes.
3.5. Languages
Language information is encoded according to BCP 47 (http://tools.ietf.org/html/bcp47). This is a document which concatenates two RFCs (5646 and 5645) and defines values of language tags to be used. Examples include en for English, en-CA for Canadian English, and ja-JP for Japanese as used in Japan.
3.6. Client-originated Identifiers
The system allows clients to submit arbitrary identifiers during trading (so that the client can distinguish orders on its side). Client-originated identifiers can comprise any latin alphanumeric characters (A..Z,a..z,0..9) and any of the following special characters:
~ , . - _ / \ : ; ! @ ‘ “ # $ % ^ & ? * ( ) [ ] = + \`
Length of a client-originated identifier should not exceed 64 characters.
Identifiers are case-sensitive (so that ‘Aa’ and ‘AA’ are two different identifiers).
The API rejects requests if an identifier contains any characters other than listed above or its length exceeds 64 characters.
Client-originated identifiers must be URL-encoded when used in queries (see https://en.wikipedia.org/wiki/Percent-encoding).
3.7. Account Code
Accounts in the system are addressed with a two-component account code that uniquely corresponds to a single account in the system. Account code is assigned by the system and is of 'clearing:account' format (two strings separated with a colon).
Account code should be URL-encoded when used in HTTP queries (see https://en.wikipedia.org/wiki/Percent-encoding).
3.8. Order Statuses
An order can be in one of the following statuses:
| Status | Details |
|---|---|
ACCEPTED |
Order has been accepted by the system. |
WORKING |
An order is working in the system: either pending execution or (in case of limit or stop order) waiting for a trigger quote |
CANCELED |
Order has been cancelled in its entirety. This is a final state. |
COMPLETED |
Order has been filled (either completely or partially). This is a final state. |
EXPIRED |
Order has been expired. This is a final state. |
REJECTED |
Order has been rejected. This is a final state. |
IN_REVIEW |
Order has been put in review. |
4. Security Aspects
4.1. Transport Protocol Security
The REST API is deployed to work over secure transport protocol such as HTTPS (see http://en.wikipedia.org/wiki/Https) or secure VPN. The protocol must ensure that no traffic towards and from the API is exposed to public unencrypted.
The REST API can be configured to support the HTTP strict transport
security standard (http://tools.ietf.org/html/rfc6797).
The following response header is sent to any client on REST API login to
indicate that only HTTPS is supported for the API host:
Strict-Transport-Security: max-age=31536000. See Basic Authentication.
4.2. Authentication
The following authentication types are supported:
Basic Authentication |
This is the simplest type of password-based authentication. Man-in-the-middle attacks are prohibited by the secure transport protocol (see Transport Protocol Security). This authentication method is primarily for browser-based and other B2C applications. See Authentication & Authorization API for detailed description. |
HMAC Authentication |
This is the type of authentication to be employed for integrations with advanced requirements to security; it also shall be the default way of authentication for integrations that permit trading on behalf of multiple accounts. |
4.3. API Throttling
The REST API supports per-client configurable maximum API access rate. This rate limits how frequently the API can be accessed. There are three types of rate limits:
-
For login requests based on IP of the request. Default value - 1 per second
-
For 'get data' requests based on client session, default value - 2 per second.
-
For trading requests(placing / modifying / canceling orders) based on client session, default value - 1 per second.
If access rate is exceeded, the server responds with 429 Too Many Requests.
4.4. Request Length Limit
DX REST API rejects any request if it exceeds the maximum configurable
length. This is a security measure to avoid DDoS attacks. Default
maximum length is 512Kb. The server responds with 413 Request Entity Too
Large to any request that exceeds the maximum allowed length.
5. Authentication & Authorization API
5.1. General Technical Details
Due to stateless nature of REST API, there is no strict notion of a user "session". Each request may be treated as a separate session, especially in case of HMAC Authentication when there is no separate "login" phase. That’s why the system treats user sessions differently depending on the authentication type:
-
Basic authentication – client is considered logged in from the moment the "login" request completes successfully until any of the following events occur:
-
"Logout" is requested explicitly by the client or by the platform itself
-
More than a predefined timeout passes since the last request to the API
-
-
HMAC authentication – client is considered logged in from the moment of any first request until a predefined timeout passes since last request.
5.2. Basic Authentication
Details
Basic authentication is the simplest authentication type best suited for simple B2C integration when security requirements are not high. It also consumes fewer resources on server and client side.
DX REST API basic authentication should not be mistaken for standard HTTP Basic Authentication; these are different.
For this authentication type, username, domain and password are required.
To login on behalf of another user LOGIN_ON_BEHALF permission is required.
High-Level Overview
-
User POSTs their username, domain and password to a special login resource
-
Server validates the credentials
-
Server generates a random access token which is returned to the client
-
Client receives the token and uses it in all further requests supplying it in a header.
-
Token expires due to:
-
Client POSTs a request to a special "logout" resource (see Logout)
-
Client is forced to log out by the platform operations team
-
Client is revoked the permission to use the REST API
-
A pre-configured timeout passes since last request from the client
-
-
Upon a request with an expired token, client receives a
401 Unauthorizederror and is expected to repeat the authentication procedure. -
To avoid situations with sudden disconnects due to inactivity, client is expected to track token expiration on its side and either renew the session or use the Ping API to maintain the session. See Ping API.
Resource
https://<api>/<path>/login
Description
Performs a basic authentication login to the REST API; returns a token to be used in all further requests.
After authentication is performed successfully, a requesting party shall include the following header with each further request:
Authorization: DXAPI <session token>
Method
POST
Request Data
username |
Login of the client in the system |
domain |
Domain of the client |
password |
Password of the client |
Returns
sessionToken |
Authentication token to be used in all further requests |
timeout |
Time interval after which token expires due to inactivity (see Times and Dates) |
Special Response Headers
If configured, response includes the following header:
Strict-Transport-Security: max-age=31536000
See Transport Protocol Security for details.
Errors
Authentication failed due to username/password mismatch
| Status code | Error code | Description |
|---|---|---|
401 Unauthorized |
3 |
Incorrect username or password |
5.3. HMAC Authentication
Details
HMAC authentication is most suitable for large B2B integrations with high security demands. It provides a digital signature for each request that guarantees that the request hasn’t been tampered with.
For this type of authentication a pair of private and public API tokens is used. This pair of tokens is generated and provided to a client during onboarding phase and is out of scope of this document. Tokens shall be the globally unique GUID identifiers of 128bit size.
Standard HMAC digital signature can be applied to all the requests and responses if configured for the client (see http://en.wikipedia.org/wiki/Hash-based_message_authentication_code). HMAC is included in each request coming from the client and each response returned to the client. This allows for verifying that requests and responses come from the stated parties and have not been tampered with.
High-Level Overview
-
Generate a public/private token pair for the customer.
-
The public/private token pair is shared with the client during the "onboarding" phase. This is done via a manual process and does not involve any API or backend component.
-
HMAC works as follows:
-
[CLIENT] Create the string to be hashed (hash candidate) from the request data. The following request data shall be used for hash candidate: HTTP method, request content, URI, timestamp.
-
[CLIENT] Using the SHA2-256 algorithm and the private token, create the HMAC hash of the hash candidate.
-
[CLIENT] Include HMAC hash and the timestamp used to generate it into request.
-
[SERVER] Check the timestamp in the request against the current server system time and validate that the difference between them is within a configurable range of time. Reject if time difference is out of range.
-
[SERVER] Using the public token and any of the other necessary identifier information, retrieve the private token from the database.
-
[SERVER] Generate the HMAC hash in exactly the same manner as created by the Client (see [a] and [b] above).
-
[SERVER] Compare the HMAC generated on the server with that received from the client. If they match, process the command. If they don’t match, reject the request.
-
[SERVER] Generate a response and sign it with HMAC exactly as described above. This would allow customers to validate response if needed.
-
Resource
Any resource
Description
Generate an HMAC digital signature and add it to any request. No special login step is needed.
Method
Any method.
Special Request Headers
Authorization: DXAPI principal="<API principal>",timestamp=<timestamp>,hash="<HMAC hash>"
Where:
-
<API principal> is the public API token of the client obtained during onboarding
-
<timestamp> is the timestamp used to calculate hash candidate, see (1) below, UNIX milliseconds since epoch.
-
<HMAC hash> is the hash calculated at step (3) below, in BASE64 encoding.
For any request to the API, the client generates a HMAC hash for HMAC signature according to the following algorithm:
-
Create a set of key-value pairs with the following keys and values separated by '=' exactly in the order provided in the table:
Key Value Method
HTTP Method used for this request
Content
Content of the request / response exactly as it will be sent. If empty, empty string shall be used.
URI
URI of the resource with all the query parameters, without the <host> part, e.g. for https://myhost.com/api/request?x=y use the '/api/request?x=y' string.
Timestamp
Timestamp of the request as milliseconds since epoch; see Times and Dates.
Token
Private token of the API client
-
Concatenate all the pairs above using the new line character ('\n') as a separator.
Sample hash candidateMethod=GET Content= URI=/dxsca-web/orders/334 Timestamp=1464264688310
-
Calculate the <HMAC hash> by applying SHA2-256 algorithm to the hash candidate.
Returns
For any request to the API with the Authorization HMAC header set, the server:
-
Validates the correctness of the header
-
Validates that the <timestamp> is within the acceptable pre-configured range from the current timestamp.
-
Generates the HMAC hash for the request similar to the client (see steps above) and compares the hash with the one received in request.
-
Computes a response for the request
Errors
See Common Errors.
Special Response Headers
If it is configured that the server should send HMAC signature in response for this client, the server computes HMAC signature for the response and include the following header so that the client is also able to verify HMAC signature on its side:
X-HMAC-Signature: DXAPI principal="<API principal>",timestamp=<timestamp>,hash="<HMAC hash>"
5.4. Ping API
Details
Since in certain authentication types there is a timeout after which the session is considered expired, there is a risk that a client who is not active may run into situation when he’s not able to trade as fast as needed due to a sudden need to re-authenticate. To avoid such issues, there is an API that lets the client periodically "ping" the server without actually doing anything to indicate that the session is still active and should not expire. There is no need to use this API if HMAC Authentication is used.
Only sessions registered via this rest API will be prolonged, other sessions should be prolonged via administrative rest API.
Resource
https://<host>/<path>/ping
Description
For clients authenticated with basic authentication (see Basic Authentication) resets the session expiration timeout.
Method
POST
Special Request Headers
Authorization header in case of Basic Authentication (see Basic Authentication).
Request Data
Empty request.
Returns
sessionToken |
Authentication token to be used in all further requests
(the same as was passed via |
timeout |
Time interval after which token expires due to inactivity (see Times and Dates) |
Errors
See Common Errors for authentication-related errors.
5.5. Logout
Details
In case the client has authorization token created by Basic Authentication (see Basic Authentication) process and does not plan to use DX API anymore it is recommended to explicitly expire authorization token to free up system resources.
Resource
https://<host>/<path>/logout
Description
For clients authenticated with basic authentication (see Basic Authentication) explicitly expires authorization token.
Method
POST
Special Request Headers
Authorization header in case of Basic Authentication (see Basic Authentication).
Request Data
Empty request.
Returns
Empty response.
Errors
See Common Errors for authentication-related errors.
6. Trading API
6.1. Place Order
Details
The API allows submitting a new order or a group of orders on an account. User can always issue orders on his own accounts, but can only issue orders on behalf of other accounts if corresponding permissions are configured.
Since the API may return different results to different users, its results are not cached.
The API is via POST, so it’s not idempotent. To avoid issues with duplicate orders, a client is expected to submit a client-unique id of an order with the request. This id is used to track the order later on. See Client-originated Identifiers.
Resource
https://<host>/<path>/accounts/<account code>/orders
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding). See Account Code.
Method
POST
Request Data
A request to create a single order (see Single Order Request), a multileg order (see Multileg Order Request) or an order group (see Order Group Request).
Returns
Order response or a list of order responses for all orders in a group (if a group was submitted); see Order Response and Order Response List.
Examples
-
Create "IF-THEN" order group (see Order Group Request) with several then-s.
Request body:
{ "orders": [ { "orderCode": "o1", "type": "LIMIT", "instrument": "AAPL", "quantity": 11, "positionEffect": "OPEN", "side": "BUY", "limitPrice": 11, "tif": "DAY" }, { "orderCode": "o2", "type": "LIMIT", "instrument": "AAPL", "quantity": 12, "positionEffect": "OPEN", "side": "BUY", "limitPrice": 12, "tif": "DAY" }, { "orderCode": "o3", "type": "LIMIT", "instrument": "AAPL", "quantity": 13, "positionEffect": "OPEN", "side": "BUY", "limitPrice": 13, "tif": "DAY" }, { "orderCode": "o4", "type": "LIMIT", "instrument": "AAPL", "quantity": 14, "positionEffect": "OPEN", "side": "BUY", "limitPrice": 14, "tif": "DAY" }, { "orderCode": "o5", "type": "LIMIT", "instrument": "AAPL", "quantity": 15, "positionEffect": "OPEN", "side": "BUY", "limitPrice": 15, "tif": "DAY" } ], "contingencyType": "IF-THEN", "ocoSubgroups": [["o2", "o3"], ["o4", "o5"]] }Response:
{ "orderResponses": [ { "orderId": 857, "updateOrderId": 857 }, { "orderId": 858, "updateOrderId": 858 }, { "orderId": 900, "updateOrderId": 900 }, { "orderId": 901, "updateOrderId": 901 }, { "orderId": 903, "updateOrderId": 903 } ] } -
Observe created order group (see List Open Orders)
Response:
{ "orders": [ { "account": "default:bro1-E", "version": 10, "orderId": 901, "orderCode": "dxsca-integration-session-code:o4", "clientOrderId": "o4", "actionCode": "dxsca-integration-session-code:o4", "legCount": 1, "type": "LIMIT", "instrument": "AAPL", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "AAPL", "positionEffect": "OPEN", "side": "BUY", "price": 14, "legRatio": 1, "quantity": 14, "filledQuantity": 0, "remainingQuantity": 14, "averagePrice": 0 } ], "side": "BUY", "tif": "DAY", "issueTime": "2023-10-27T07:09:08.958Z", "transactionTime": "2023-10-27T07:09:08.958Z", "links": [ { "linkType": "PARENT", "linkedOrder": "dxsca-integration-session-code:o1", "linkedClientOrderId": "o1" }, { "linkType": "OCO", "linkedOrder": "dxsca-integration-session-code:o5", "linkedClientOrderId": "o5" } ], "executions": [ { "account": "default:bro1-E", "executionCode": "100:58", "orderCode": "dxsca-integration-session-code:o4", "updateOrderId": 901, "version": 10, "clientOrderId": "o4", "actionCode": "dxsca-integration-session-code:o4", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "lastQuantity": 0, "filledQuantityNotional": 0, "lastQuantityNotional": 0, "transactionTime": "2023-10-27T07:09:08.958Z" } ], "cashTransactions": [] }, { "account": "default:bro1-E", "version": 14, "orderId": 857, "orderCode": "dxsca-integration-session-code:o1", "clientOrderId": "o1", "actionCode": "dxsca-integration-session-code:o1", "legCount": 1, "type": "LIMIT", "instrument": "AAPL", "status": "ACCEPTED", "finalStatus": false, "legs": [ { "instrument": "AAPL", "positionEffect": "OPEN", "side": "BUY", "price": 11, "legRatio": 1, "quantity": 11, "filledQuantity": 0, "remainingQuantity": 11, "averagePrice": 0 } ], "side": "BUY", "tif": "DAY", "issueTime": "2023-10-27T07:09:08.958Z", "transactionTime": "2023-10-27T07:09:08.958Z", "links": [ { "linkType": "CHILD", "linkedOrder": "dxsca-integration-session-code:o2", "linkedClientOrderId": "o2" }, { "linkType": "CHILD", "linkedOrder": "dxsca-integration-session-code:o3", "linkedClientOrderId": "o3" }, { "linkType": "CHILD", "linkedOrder": "dxsca-integration-session-code:o4", "linkedClientOrderId": "o4" }, { "linkType": "CHILD", "linkedOrder": "dxsca-integration-session-code:o5", "linkedClientOrderId": "o5" } ], "executions": [ { "account": "default:bro1-E", "executionCode": "100:64", "orderCode": "dxsca-integration-session-code:o1", "updateOrderId": 857, "version": 14, "clientOrderId": "o1", "actionCode": "dxsca-integration-session-code:o1", "status": "ACCEPTED", "finalStatus": false, "filledQuantity": 0, "lastQuantity": 0, "filledQuantityNotional": 0, "lastQuantityNotional": 0, "transactionTime": "2023-10-27T07:09:08.958Z" } ], "cashTransactions": [] }, { "account": "default:bro1-E", "version": 8, "orderId": 858, "orderCode": "dxsca-integration-session-code:o2", "clientOrderId": "o2", "actionCode": "dxsca-integration-session-code:o2", "legCount": 1, "type": "LIMIT", "instrument": "AAPL", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "AAPL", "positionEffect": "OPEN", "side": "BUY", "price": 12, "legRatio": 1, "quantity": 12, "filledQuantity": 0, "remainingQuantity": 12, "averagePrice": 0 } ], "side": "BUY", "tif": "DAY", "issueTime": "2023-10-27T07:09:08.958Z", "transactionTime": "2023-10-27T07:09:08.958Z", "links": [ { "linkType": "PARENT", "linkedOrder": "dxsca-integration-session-code:o1", "linkedClientOrderId": "o1" }, { "linkType": "OCO", "linkedOrder": "dxsca-integration-session-code:o3", "linkedClientOrderId": "o3" } ], "executions": [ { "account": "default:bro1-E", "executionCode": "100:56", "orderCode": "dxsca-integration-session-code:o2", "updateOrderId": 858, "version": 8, "clientOrderId": "o2", "actionCode": "dxsca-integration-session-code:o2", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "lastQuantity": 0, "filledQuantityNotional": 0, "lastQuantityNotional": 0, "transactionTime": "2023-10-27T07:09:08.958Z" } ], "cashTransactions": [] }, { "account": "default:bro1-E", "version": 9, "orderId": 900, "orderCode": "dxsca-integration-session-code:o3", "clientOrderId": "o3", "actionCode": "dxsca-integration-session-code:o3", "legCount": 1, "type": "LIMIT", "instrument": "AAPL", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "AAPL", "positionEffect": "OPEN", "side": "BUY", "price": 13, "legRatio": 1, "quantity": 13, "filledQuantity": 0, "remainingQuantity": 13, "averagePrice": 0 } ], "side": "BUY", "tif": "DAY", "issueTime": "2023-10-27T07:09:08.958Z", "transactionTime": "2023-10-27T07:09:08.958Z", "links": [ { "linkType": "PARENT", "linkedOrder": "dxsca-integration-session-code:o1", "linkedClientOrderId": "o1" }, { "linkType": "OCO", "linkedOrder": "dxsca-integration-session-code:o2", "linkedClientOrderId": "o2" } ], "executions": [ { "account": "default:bro1-E", "executionCode": "100:57", "orderCode": "dxsca-integration-session-code:o3", "updateOrderId": 900, "version": 9, "clientOrderId": "o3", "actionCode": "dxsca-integration-session-code:o3", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "lastQuantity": 0, "filledQuantityNotional": 0, "lastQuantityNotional": 0, "transactionTime": "2023-10-27T07:09:08.958Z" } ], "cashTransactions": [] }, { "account": "default:bro1-E", "version": 11, "orderId": 903, "orderCode": "dxsca-integration-session-code:o5", "clientOrderId": "o5", "actionCode": "dxsca-integration-session-code:o5", "legCount": 1, "type": "LIMIT", "instrument": "AAPL", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "AAPL", "positionEffect": "OPEN", "side": "BUY", "price": 15, "legRatio": 1, "quantity": 15, "filledQuantity": 0, "remainingQuantity": 15, "averagePrice": 0 } ], "side": "BUY", "tif": "DAY", "issueTime": "2023-10-27T07:09:08.958Z", "transactionTime": "2023-10-27T07:09:08.958Z", "links": [ { "linkType": "PARENT", "linkedOrder": "dxsca-integration-session-code:o1", "linkedClientOrderId": "o1" }, { "linkType": "OCO", "linkedOrder": "dxsca-integration-session-code:o4", "linkedClientOrderId": "o4" } ], "executions": [ { "account": "default:bro1-E", "executionCode": "100:59", "orderCode": "dxsca-integration-session-code:o5", "updateOrderId": 903, "version": 11, "clientOrderId": "o5", "actionCode": "dxsca-integration-session-code:o5", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "lastQuantity": 0, "filledQuantityNotional": 0, "lastQuantityNotional": 0, "transactionTime": "2023-10-27T07:09:08.958Z" } ], "cashTransactions": [] } ] }
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is sent in response for a single order request only. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
-
API is not permitted for the user or account with the given id doesn’t exist or account with the given id is not accessible for the user
Status code Error code Description 404 Not Found
2
Entity not found at server
-
Order request or order group is not well-formed or is semantically incorrect (e.g. limit order doesn’t have price or order group includes both OCO and Contingent fields).
Status code Error code Description 400 Bad Request
33
Incorrect request (<details about an error>).
-
Order didn’t pass pre-issue check.
Status code Error code Description 409 Conflict
<various>
<various>
-
Order with such a client order id already exists in the system.
Status code Error code Description 409 Conflict
100
Order with this id already exists (<client order id>)
-
Client order id is invalid (see Client-originated Identifiers)
Status code Error code Description 400 Bad Request
101
Client-originated identifier is not valid
6.2. Modify Order
Details
This API allows editing order details on an account. User can always edit orders on his own accounts, but can only edit orders on behalf of other accounts if a special permission is set.
Since the API may return different results to different users, its results are not cached.
The API is via PUT and is idempotent. Only conditional requests are accepted (see Conditional Requests & Updates).
Resource
https://<host>/<path>/accounts/<account code>/orders
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding)
Method
PUT
Request Data
An order request (see Single Order Request, Multileg Order Request or an order group Order Group Request)
that has some of the fields changed. User must submit the whole order request to
ensure idempotency of the protocol. Some of the fields cannot be changed
after order is issued; attempt to do so will result in 409 Conflict
error.
Note, API supports modifying of order group by single order or single order by order group.
Returns
Updated order response or a list of order responses for all orders in a group (if a group was submitted); see Order Response and Order Response List.
Examples
-
Create "IF-THEN" order group (see Order Group Request)
Request body:
{"orders": [{ "orderCode":"80t1", "type":"LIMIT", "instrument":"EUR/USD", "quantity":"300000", "positionEffect":"OPEN", "side":"BUY", "limitPrice":"0.05", "tif":"GTC" }, { "orderCode":"80t2", "type":"STOP", "instrument":"EUR/USD", "quantity":"0", "positionEffect":"CLOSE", "side":"SELL", "stopPrice":"0.7", "tif":"GTC" }, { "orderCode":"80t3", "type":"LIMIT", "instrument":"EUR/USD", "quantity":"0", "positionEffect":"CLOSE", "side":"SELL", "limitPrice":"1.3", "tif":"GTC" } ], "contingencyType":"IF-THEN"}Response:
{ "orderResponses": [ { "orderId": 46072658, "updateOrderId": 46072658 }, { "orderId": 46072659, "updateOrderId": 46072659 }, { "orderId": 46072660, "updateOrderId": 46072660 } ] } -
Observe created order group (see List Open Orders)
Response:
{ "account": "default:ssp1", "version": 447, "orderId": 46072658, "orderCode": "dxsca-integration-session-code:80t1", "clientOrderId": "80t1", "actionCode": "dxsca-integration-session-code:80t1", "legCount": 1, "type": "LIMIT", "instrument": "EUR/USD", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "EUR/USD", "positionEffect": "OPEN", "side": "BUY", "price": 0.05, "legRatio": 1, "quantity": 300000, "filledQuantity": 0, "remainingQuantity": 300000 } ], "side": "BUY", "tif": "GTC", "issueTime": "2017-08-28T14:19:31.731Z", "transactionTime": "2017-08-28T14:19:31.731Z", "links": [ { "linkType": "CHILD", "linkedOrder": "dxsca-integration-session-code:80t2", "linkedClientOrderId": "80t2" }, { "linkType": "CHILD", "linkedOrder": "dxsca-integration-session-code:80t3", "linkedClientOrderId": "80t3" } ], "executions": [ { "account": "default:ssp1", "executionCode": "816051:16502", "orderCode": "dxsca-integration-session-code:80t1", "updateOrderId": 46072658, "version": 447, "clientOrderId": "80t1", "actionCode": "dxsca-integration-session-code:80t1", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "transactionTime": "2017-08-28T14:19:31.731Z" } ], "cashTransactions": [] }, { "account": "default:ssp1", "version": 448, "orderId": 46072659, "orderCode": "dxsca-integration-session-code:80t2", "clientOrderId": "80t2", "actionCode": "dxsca-integration-session-code:80t2", "legCount": 1, "type": "STOP", "instrument": "EUR/USD", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "EUR/USD", "positionEffect": "CLOSE", "side": "BUY", "price": 0.7, "legRatio": 1, "filledQuantity": 0 } ], "side": "SELL", "tif": "GTC", "issueTime": "2017-08-28T14:19:31.731Z", "transactionTime": "2017-08-28T14:19:31.731Z", "links": [ { "linkType": "PARENT", "linkedOrder": "dxsca-integration-session-code:80t1", "linkedClientOrderId": "80t1" } ], "executions": [ { "account": "default:ssp1", "executionCode": "816051:16503", "orderCode": "dxsca-integration-session-code:80t2", "updateOrderId": 46072659, "version": 448, "clientOrderId": "80t2", "actionCode": "dxsca-integration-session-code:80t2", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "transactionTime": "2017-08-28T14:19:31.731Z" } ], "cashTransactions": [] }, { "account": "default:ssp1", "version": 449, "orderId": 46072660, "orderCode": "dxsca-integration-session-code:80t3", "clientOrderId": "80t3", "actionCode": "dxsca-integration-session-code:80t3", "legCount": 1, "type": "LIMIT", "instrument": "EUR/USD", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "EUR/USD", "positionEffect": "CLOSE", "side": "BUY", "price": 1.3, "legRatio": 1, "filledQuantity": 0 } ], "side": "SELL", "tif": "GTC", "issueTime": "2017-08-28T14:19:31.731Z", "transactionTime": "2017-08-28T14:19:31.731Z", "links": [ { "linkType": "PARENT", "linkedOrder": "dxsca-integration-session-code:80t1", "linkedClientOrderId": "80t1" } ], "executions": [ { "account": "default:ssp1", "executionCode": "816051:16504", "orderCode": "dxsca-integration-session-code:80t3", "updateOrderId": 46072660, "version": 449, "clientOrderId": "80t3", "actionCode": "dxsca-integration-session-code:80t3", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "transactionTime": "2017-08-28T14:19:31.731Z" } ], "cashTransactions": [] } -
Create modify single order (see Single Order Request). Here
quantityandlimitPricewere changedRequest:
{ "orderCode":"80t1", "instrument":"EUR/USD", "quantity":"200000", "positionEffect":"OPEN", "side":"BUY", "limitPrice":"0.04", "tif":"GTC" }Response:
{ "orderId": 46072658, "updateOrderId": 46073016 } -
Observe created orders (see List Open Orders) and see that changes has been applied
Response:
{ "account": "default:ssp1", "version": 452, "orderId": 46072658, "orderCode": "dxsca-integration-session-code:80t1", "clientOrderId": "80t1", "actionCode": "816099:2", "legCount": 1, "type": "LIMIT", "instrument": "EUR/USD", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "EUR/USD", "positionEffect": "OPEN", "side": "BUY", "price": 0.04, "legRatio": 1, "quantity": 200000, "filledQuantity": 0, "remainingQuantity": 200000 } ], "side": "BUY", "tif": "GTC", "issueTime": "2017-08-28T14:19:31.731Z", "transactionTime": "2017-08-28T14:38:18.420Z", "executions": [ { "account": "default:ssp1", "executionCode": "816051:16502", "orderCode": "dxsca-integration-session-code:80t1", "updateOrderId": 46072658, "version": 447, "clientOrderId": "80t1", "actionCode": "816099:2", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "transactionTime": "2017-08-28T14:19:31.731Z" }, { "account": "default:ssp1", "executionCode": "816051:16755", "orderCode": "dxsca-integration-session-code:80t1", "updateOrderId": 46073016, "version": 451, "clientOrderId": "80t1", "actionCode": "816099:2", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "transactionTime": "2017-08-28T14:38:18.420Z" }, { "account": "default:ssp1", "executionCode": "816051:16756", "orderCode": "dxsca-integration-session-code:80t1", "updateOrderId": 46072658, "version": 452, "clientOrderId": "80t1", "actionCode": "816099:2", "status": "WORKING", "finalStatus": true, "filledQuantity": 0, "transactionTime": "2017-08-28T14:38:18.420Z" } ], "cashTransactions": [] }
-
Create single Limit order (see Single Order Request)
Request:
{ "orderCode":"7651dd", "type":"LIMIT", "instrument":"EUR/USD", "quantity":"300000", "positionEffect":"OPEN", "side":"BUY", "limitPrice":"0.05", "tif":"GTC" }Response:
{ "orderId": 46073148, "updateOrderId": 46073148 } -
Observe created order (see List Open Orders)
Response:
{ "account": "default:ssp1", "version": 460, "orderId": 46073148, "orderCode": "dxsca-integration-session-code:7651dd", "clientOrderId": "7651dd", "actionCode": "dxsca-integration-session-code:7651dd", "legCount": 1, "type": "LIMIT", "instrument": "EUR/USD", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "EUR/USD", "positionEffect": "OPEN", "side": "BUY", "price": 0.05, "legRatio": 1, "quantity": 300000, "filledQuantity": 0, "remainingQuantity": 300000 } ], "side": "BUY", "tif": "GTC", "issueTime": "2017-08-28T14:42:53.496Z", "transactionTime": "2017-08-28T14:42:53.496Z", "executions": [ { "account": "default:ssp1", "executionCode": "816051:16833", "orderCode": "dxsca-integration-session-code:7651dd", "updateOrderId": 46073148, "version": 460, "clientOrderId": "7651dd", "actionCode": "dxsca-integration-session-code:7651dd", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "transactionTime": "2017-08-28T14:42:53.496Z" } ], "cashTransactions": [] } -
Create "IF-THEN" modifying order group (see Order Group Request). Here
quantityandlimitPricewere changedRequest:
{"orders": [ { "orderCode":"7651dd", "instrument":"EUR/USD", "quantity":"200000", "positionEffect":"OPEN", "side":"BUY", "limitPrice":"0.003", "tif":"GTC" }, { "orderCode":"892", "instrument":"EUR/USD", "quantity":"0", "positionEffect":"CLOSE", "side":"SELL", "stopPrice":"0.7", "tif":"GTC" }, { "orderCode":"354", "instrument":"EUR/USD", "quantity":"0", "positionEffect":"CLOSE", "side":"SELL", "limitPrice":"1.3", "tif":"GTC" } ], "contingencyType":"IF-THEN"}Response:
{ "orderResponses": [ { "orderId": 46073148, "updateOrderId": 46073191 }, { "orderId": 46073192, "updateOrderId": 46073192 }, { "orderId": 46073193, "updateOrderId": 46073193 } ] } -
Observe created order with
orderId = 45974088(see List Open Orders) and see that changes has been appliedResponse:
{ "account": "default:ssp1", "version": 465, "orderId": 46073148, "orderCode": "dxsca-integration-session-code:7651dd", "clientOrderId": "7651dd", "actionCode": "816099:3", "legCount": 1, "type": "LIMIT", "instrument": "EUR/USD", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "EUR/USD", "positionEffect": "OPEN", "side": "BUY", "price": 0.003, "legRatio": 1, "quantity": 200000, "filledQuantity": 0, "remainingQuantity": 200000 } ], "side": "BUY", "tif": "GTC", "issueTime": "2017-08-28T14:42:53.496Z", "transactionTime": "2017-08-28T14:46:28.686Z", "links": [ { "linkType": "CHILD", "linkedOrder": "816099:4", "linkedClientOrderId": "4" }, { "linkType": "CHILD", "linkedOrder": "816099:5", "linkedClientOrderId": "5" } ], "executions": [ { "account": "default:ssp1", "executionCode": "816051:16833", "orderCode": "dxsca-integration-session-code:7651dd", "updateOrderId": 46073148, "version": 460, "clientOrderId": "7651dd", "actionCode": "816099:3", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "transactionTime": "2017-08-28T14:42:53.496Z" }, { "account": "default:ssp1", "executionCode": "816051:16874", "orderCode": "dxsca-integration-session-code:7651dd", "updateOrderId": 46073191, "version": 464, "clientOrderId": "7651dd", "actionCode": "816099:3", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "transactionTime": "2017-08-28T14:46:28.686Z" }, { "account": "default:ssp1", "executionCode": "816051:16875", "orderCode": "dxsca-integration-session-code:7651dd", "updateOrderId": 46073148, "version": 465, "clientOrderId": "7651dd", "actionCode": "816099:3", "status": "WORKING", "finalStatus": true, "filledQuantity": 0, "transactionTime": "2017-08-28T14:46:28.686Z" } ], "cashTransactions": [] }, { "account": "default:ssp1", "version": 466, "orderId": 46073192, "orderCode": "816099:4", "clientOrderId": "4", "actionCode": "816099:4", "legCount": 1, "type": "STOP", "instrument": "EUR/USD", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "EUR/USD", "positionEffect": "CLOSE", "side": "BUY", "price": 0.7, "legRatio": 1, "filledQuantity": 0 } ], "side": "SELL", "tif": "GTC", "issueTime": "2017-08-28T14:46:28.686Z", "transactionTime": "2017-08-28T14:46:28.686Z", "links": [ { "linkType": "PARENT", "linkedOrder": "dxsca-integration-session-code:7651dd", "linkedClientOrderId": "7651dd" } ], "executions": [ { "account": "default:ssp1", "executionCode": "816051:16876", "orderCode": "816099:4", "updateOrderId": 46073192, "version": 466, "clientOrderId": "4", "actionCode": "816099:4", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "transactionTime": "2017-08-28T14:46:28.686Z" } ], "cashTransactions": [] }, { "account": "default:ssp1", "version": 467, "orderId": 46073193, "orderCode": "816099:5", "clientOrderId": "5", "actionCode": "816099:5", "legCount": 1, "type": "LIMIT", "instrument": "EUR/USD", "status": "WORKING", "finalStatus": false, "legs": [ { "instrument": "EUR/USD", "positionEffect": "CLOSE", "side": "BUY", "price": 1.3, "legRatio": 1, "filledQuantity": 0 } ], "side": "SELL", "tif": "GTC", "issueTime": "2017-08-28T14:46:28.686Z", "transactionTime": "2017-08-28T14:46:28.686Z", "links": [ { "linkType": "PARENT", "linkedOrder": "dxsca-integration-session-code:7651dd", "linkedClientOrderId": "7651dd" } ], "executions": [ { "account": "default:ssp1", "executionCode": "816051:16877", "orderCode": "816099:5", "updateOrderId": 46073193, "version": 467, "clientOrderId": "5", "actionCode": "816099:5", "status": "WORKING", "finalStatus": false, "filledQuantity": 0, "transactionTime": "2017-08-28T14:46:28.686Z" } ], "cashTransactions": [] }
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is sent in response. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
-
API is not permitted for the user or account with the given id doesn’t exist or account with the given id is not accessible for the user or order with such an id is not found.
Status code Error code Description 404 Not Found
2
Entity not found at server
-
Order request is not well-formed or is semantically incorrect (e.g. limit order doesn’t have price).
Status code Error code Description 400 Bad Request
33
Incorrect request (<details about an error>).
-
An attempt is made to edit parameters that cannot be edited (such as order id or order type).
Status code Error code Description 409 Conflict
<various>
<various>
-
Order didn’t pass validation.
Status code Error code Description 409 Conflict
<various>
<various>
-
User didn’t submit the conditional request header (If-Match).
Status code Error code Description 403 Forbidden
99
Conditional request required
-
Conditional request header (If-Match) doesn’t match current order state.
Status code Error code Description 412 Precondition Failed
N/A
N/A
6.3. Cancel Order
Details
This API allows canceling order on an account. User can always cancel orders on his own accounts, but can only cancel orders on behalf of other accounts if a special permission is set. The request can be used to cancel a single or a multileg order.
Since the API may return different results to different users, its results are not cached.
The API is via DELETE and is idempotent. Only conditional requests are accepted (see Conditional Requests & Updates).
Resource
https://<host>/<path>/accounts/<account code>/orders/<order code>
https://<host>/<path>/accounts/<account code>/orders/group
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding)
-
order code can be either a client order id (assigned by the client during order placement) or an internal code assigned by the system ("action key" of the order chain). The code should be URL-encoded.
Server shall apply the following logic when selecting an order to cancel:
-
URL-decode the order code
-
If order code is in the '<a>:<b>' format and there exists an order with this internal code, treat order code as an internal code
-
Otherwise treat order code as client-originated order identifier
The following query arguments are supported for /orders/group resource:
order-codes |
Comma-separated list of order codes(see description above). Note, that order in list is important for groups with parent, first order in list is parent, next orders are children. |
contingency-type |
Contingency type of order group to cancel. |
Method
DELETE
Request Data
Empty request.
Returns
Order response for cancelled order or a list of order responses for all orders in a group (if a group was submitted); see Order Response and Order Response List.
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is not sent in response. See Conditional Requests & Updates.
Errors
See Common Errors for authentication-related errors.
-
API is not permitted for the user or account with the given id doesn’t exist or account with the given id is not accessible for the user or order with such an id is not found.
Status code Error code Description 404 Not Found
2
Entity not found at server
-
An attempt is made to cancel order which cannot be cancelled (e.g. is already in final state).
Status code Error code Description 409 Conflict
<various>
<various>
-
User didn’t submit the conditional request header (If-Match).
Status code Error code Description 403 Forbidden
99
Conditional request required
-
Conditional request header (If-Match) doesn’t match current order state.
Status code Error code Description 412 Precondition Failed
N/A
N/A
6.4. Validate Order
Details
The API allows validating a new order or a group of orders on an account. User can always validate orders on his own accounts, but can only validate orders on behalf of other accounts if corresponding permissions are configured.
Since the API may return different results to different users, its results are not cached.
The API is via POST, so it’s not idempotent.
Resource
https://<host>/<path>/accounts/<account code>/orders/validate
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding). See Account Code.
Method
POST
Request Data
A request to create a single order (see Single Order Request), a multileg order (see Multileg Order Request) or an order group (see Order Group Request).
Returns
Object with orders validation result; see Validate Order Response.
Examples
-
Validate single leg order (see Single Order Request)
Request body:
{ "orderCode": "o1", "type": "MARKET", "instrument": "AAPL", "quantity": 3, "positionEffect": "OPEN", "side": "BUY", "tif": "DAY" }Response:
{ "validationResult": "NOT_RESTRICTED", "commissions": [ { "clientOrderId": "o1", "value": 5.5 } ], "fees": [ { "clientOrderId": "o1", "value": 3.3 } ] } -
Validate multileg order (see Multileg Order Request)
Request body:
{ "orderCode": "o1", "type": "MARKET", "quantity": 100, "legs": [ { "instrument": ".GOOG260116P90", "side": "BUY", "positionEffect": "OPEN" }, { "instrument": ".GOOG260116P95", "side": "BUY", "positionEffect": "OPEN" } ], "tif": "DAY" }Response:
{ "validationResult": "RESTRICTED_REJECT", "failedValidationResults": [ { "clientOrderId": "o1", "validationDescriptor": "REQUIRED_PRICES_NOT_AVAILABLE", "validationDescriptorCode": 322, "message": "Instrument prices for [GOOG, .GOOG260116P95, .GOOG260116P90] are missing. Order metrics can not be calculated." }, { "clientOrderId": "o1", "validationDescriptor": "VALIDATION_OPTION_LEVEL_VIOLATION", "validationDescriptorCode": 206, "message": "Order type exceeds approved Options Level on your account. Current level: 0" }, { "clientOrderId": "o1", "validationDescriptor": "INSUFFICIENT_PROSPECTIVE_EQUITY", "validationDescriptorCode": 102, "message": "Insufficient equity. Order causes prospective equity to exceed minimum requirement 2000,00" } ], "commissions": [ { "clientOrderId": "o1", "value": "NaN" } ], "fees": [ { "clientOrderId": "o1", "value": "NaN" } ] } -
Validate "IF-THEN" order group (see Order Group Request) with several then-s.
Request body:
{ "orders": [ { "orderCode": "o1", "type": "LIMIT", "instrument": "AAPL", "quantity": 11, "positionEffect": "OPEN", "side": "BUY", "limitPrice": 11, "tif": "DAY" }, { "orderCode": "o2", "type": "LIMIT", "instrument": "AAPL", "quantity": 12, "positionEffect": "OPEN", "side": "BUY", "limitPrice": 12, "tif": "DAY" }, { "orderCode": "o3", "type": "LIMIT", "instrument": "AAPL", "quantity": 13, "positionEffect": "OPEN", "side": "BUY", "limitPrice": 13, "tif": "DAY" }, { "orderCode": "o4", "type": "LIMIT", "instrument": "AAPL", "quantity": 14, "positionEffect": "OPEN", "side": "BUY", "limitPrice": 14, "tif": "DAY" }, { "orderCode": "o5", "type": "LIMIT", "instrument": "AAPL", "quantity": 15, "positionEffect": "OPEN", "side": "BUY", "limitPrice": 15, "tif": "DAY" } ], "contingencyType": "IF-THEN", "ocoSubgroups": [["o2", "o3"], ["o4", "o5"]] }Response:
{ "validationResult": "NOT_RESTRICTED", "commissions": [ { "clientOrderId": "o1", "value": 5.5 }, { "clientOrderId": "o2", "value": 5.5 }, { "clientOrderId": "o3", "value": 5.5 }, { "clientOrderId": "o4", "value": 5.5 }, { "clientOrderId": "o5", "value": 5.5 } ], "fees": [ { "clientOrderId": "o1", "value": 3.3 }, { "clientOrderId": "o2", "value": 3.3 }, { "clientOrderId": "o3", "value": 3.3 }, { "clientOrderId": "o4", "value": 3.3 }, { "clientOrderId": "o5", "value": 3.3 } ] }
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is sent in response for a single order request only. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
-
API is not permitted for the user or account with the given id doesn’t exist or account with the given id is not accessible for the user
Status code Error code Description 404 Not Found
2
Entity not found at server
-
Order request or order group is not well-formed or is semantically incorrect (e.g. limit order doesn’t have price or order group includes both OCO and Contingent fields).
Status code Error code Description 400 Bad Request
33
Incorrect request (<details about an error>).
-
Client order id is invalid (see Client-originated Identifiers)
Status code Error code Description 400 Bad Request
101
Client-originated identifier is not valid
6.5. Flatten Account
Details
The API allows initiate of flattening account or part of it by a specific symbol.
Since the API may return different results to different users, its results are not cached.
The API is via POST, so it’s not idempotent.
Resource
https://<host>/<path>/accounts/<account code>/flatten
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding). See Account Code.
Method
POST
Request Data
An optional request body can contain symbol to flatten not whole account, but positions and orders by specific symbol.
Returns
Empty response if flatten was successfully initiated. Error in case of troubles.
Examples
-
Flatten whole account
Request body:
{ } -
Flatten positions and orders by specific symbol
Request body:
{ "symbol": "AAPL" }
Caching & ETag
Caching is prohibited for this resource. See Caching.
Errors
See Common Errors for authentication-related errors.
-
API is not permitted for the user or account with the given id doesn’t exist or account with the given id is not accessible for the user
Status code Error code Description 404 Not Found
2
Entity not found at server
-
There is no instrument by provided symbol
Status code Error code Description 400 Bad Request
33
Incorrect request (<details about an error>).
7. Reference Data API
7.1. List Instruments
Details
The API allows to retrieve general information about instruments currently traded in the system. The API supports searching for instruments by the following criteria:
-
Symbol (with wildcard supported)
-
Type (FX, CFD etc.)
The API is accessible to any API user but the user may be prohibited permission to some instruments or types of instruments. The instruments not permitted for the user won’t be returned and an attempt to look at details for such an instrument will result empty list of instruments. Since this request may yield different representations for different users, its response is not cached.
API returns not more than configurable count of instruments in a single response and provides paging to retrieve all the data in several requests. Link to next page(if it is exists) is embedded in the response
Resource
https://<host>/<path>/instruments/<symbol>
https://<host>/<path>/instruments/type/<type>
https://<host>/<path>/instruments/query/
where:
-
symbol – is the unique instrument symbol in the system (e.g. EUR/USD). The value should be URL-encoded.
-
type – type of the instrument in the systems (e.g. CFD). The value must be URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding.
Type and symbol parts of the resource are optional. Instruments can be queried by any combination of symbol (with wildcards supported) and type.
The following query arguments are supported:
symbols |
Symbol (or its part, URL encoded) to filter instruments. If specified, only those instruments which symbol contains the value will be returned. If not specified, all available instruments will be returned. The '*' (asterisk) wildcard indicates any number of any characters. Examples:
|
types |
Filter for the types of instruments. If not specified, instruments with all accessible types are returned. Wildcards are not supported. Several types can be indicated as comma-separated list. Examples:
|
Method
GET
Request Parameters
limit |
Maximum number of instruments to be displayed on query results page. Default value is configurable; if value more than default is provided, default value is used. |
start-from |
Indicates the starting index of instrument. Default value is 0. To use paging: set limit and start-from parameters. Ex. if limit=10, start-from=100 query results page will contain instruments from 101th to 110th |
sort-by-asc and sort-by-desc |
Specify a sorting mode for result. Only one of the two parameters is permitted. sort-by-asc specifies sorting in ascending direction; sort-by-desc specifies sorting in descending direction. Multiple comma-separated criteria are supported. Possible values are:
Default value is "sort-by-asc=SYMBOL". |
Request Data
Empty request.
Returns
A list of instruments that match the request as Instrument List object.
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is not sent in response. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
-
Request URI is malformed (cannot be matched with query criteria)
Status code Error code Description 400 Bad Request
31
Malformed query URI.
-
Request URI is malformed (request parameters are incorrect; limit or start-from are negative;)
Status code Error code Description 400 Bad Request
32
Incorrect request parameters (<request parameter that was incorrect>).
7.2. Instrument Trading Schedule
Details
The API allows retrieving general information about trading schedule for instruments currently traded in the system. The API supports retrieving trading schedule for instruments identified by the symbol for the specific date or for the current week.
The API is accessible to any user, but the user may have no permission to some instruments. The trading schedule for such instruments won’t be returned, and an attempt to look at it will result 404 http code.
Resource
https://<host>/<path>/instruments/<symbol>/schedule
where:
-
symbol – is the unique instrument symbol in the system (e.g. EUR/USD). The value should be URL-encoded. It is expected that trading schedule will be retrieved for this instrument.
Method
GET
Request Parameters
date |
The date for which there is need to request trading schedule in the ISO-8601 format. If it is not provided then trading schedule will be requested for the current week. Examples:
|
Request Data
Empty request.
Returns
Instrument trading schedule as Instrument Trading Schedule for the specific day or the current week object.
Errors
See Common Errors for authentication-related errors.
-
The requested instrument can not be found by some reasons.
Status code Error code Description 404 Not Found
2
Instrument '<symbol of requested instrument>' not found.
8. User & Account API
8.1. User Information
Details
This API permits to view details for a user. User can always view details about himself, but can only view details of other users if a special permission is set.
Since the API may return different results to different users, its results are not cached.
Resource
https://<host>/<path>/users/<username>
Where:
-
username – full user name (URL encoded) in a 'username@domain' format. Wildcards are not supported. Optional value, if omitted, all accessible users will be returned (filtered according to request parameters).
Method
GET
Request Data
Empty request.
Request Parameters
If several query parameters (e.g. in-domains, last-updated-from, last-updated-to) are provided, Boolean AND is assumed and users are returned only if they match all of the queries.
limit |
Maximum number of users to be displayed on query results page. Default value is configurable; if value more than default is provided, default value is used. |
start-from |
Indicates the starting index of user. Default value is 0. To use paging: set limit and start-from parameters. Ex. if limit=10, start-from=100 query results page will contain users from 101th to 110th |
in-domains |
Specifies a filter for user’s domain. A mask (URL encoded) cannot include wildcards. |
last-updated-from |
Time of last user’s update in UTC since which to include users. Inclusive. See Times and Dates. |
last-updated-to |
Time of last user’s update in UTC till which to include users. By default current timestamp is assumed. See Times and Dates. |
Returns
List of user details as User Details List object.
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag is sent only if details for a single user are requested. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
8.2. List Account Portfolio
Details
This API permits to view account portfolio for selected accounts. Portfolio contains of information about open positions and working orders on an account. Closed positions and completed orders are absent from the portfolio. User can always view portfolio on his own accounts, but can only view portfolio of other accounts if a special permission is set.
Since the API may return different results to different users, its results are not cached.
Resource
https://<host>/<path>/accounts/<account code>/portfolio
https://<host>/<path>/accounts/portfolio?accounts=<account codes>
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding)
-
account codes - comma-separated list of account codes (URL-encoded)
Method
GET
Request Data
Empty request.
Returns
List of account portfolio as Account Portfolio List object.
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is always sent. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
-
Any of the accounts not found or client is not permitted to access them.
Status code Error code Description 404 Not Found
2
Account(s) were not found: <comma separated list of not found accounts>.
8.3. List Open Positions
Details
This API permits to view all the open positions on specified accounts.
Since the API may return different results to different users, its results are not cached.
Resource
https://<host>/<path>/accounts/<account code>/positions
https://<host>/<path>/accounts/positions?accounts=<account codes>
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding)
-
account codes – comma-separated list of account codes (URL-encoded)
Method
GET
Request Data
Empty request.
Returns
List of open positions as Position List object.
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is always sent. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
-
Any of the accounts not found or client is not permitted to access them.
Status code Error code Description 404 Not Found
2
Account(s) were not found: <comma separated list of not found accounts>.
8.4. List Open Orders
Details
This API permits to view all the orders in non-final state on specified accounts.
Since the API may return different results to different users, its results are not cached.
Resource
https://<host>/<path>/accounts/<account code>/orders
https://<host>/<path>/accounts/orders?accounts=<account codes>
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding)
-
account codes – comma-separated list of account codes (URL-encoded)
Method
GET
Request Data
Empty request.
Returns
List of orders in non-final state as Order List object.
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is always sent. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
8.5. List Cash Transfers
Details
This API permits to query cash transfers (deposits, withdrawals etc.) for a period of time on an account or multiple accounts. This includes transfers made manually as well as transfers that are a result of position update (e.g. PnL settlement) and commissions.
Since the API may return different results to different users, its results are not cached.
Resource
https://<host>/<path>/accounts/<account code>/transfers
https://<host>/<path>/accounts/transfers?accounts=<account codes>
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding)
-
account codes – comma-separated list of account codes (URL-encoded)
Method
GET
Request Data
Empty request
Request Parameters
If several query parameters (time-from, of-type etc.) are provided, Boolean AND is assumed and transfers are returned only if they match all of the filters.
limit |
Maximum number of transfers to be displayed on query results page. Default value is configurable; if value more than default is provided, default value is used. |
start-from |
Indicates the starting index of transfer. Default value is 0. To use paging: set limit and start-from parameters. Ex. if limit=10, start-from=100 query results page will contain transfers from 101th to 110th |
of-type |
Allows specifying filter for transfer reasons. Accepts comma-separated list of reasons:
Multiple reasons are treated as "or" – a transfer that has any of these reasons is returned. |
time-from, time-to |
These two parameters specify a filter for the transfer timestamp in UTC (see Times and Dates). Filter is inclusive. If only time-from is specified, all transfers from this time until now are returned. If only time-to is specified, all transfers from the very first transfer on an account until the specified time are returned. |
period |
Shortcut filter for transfer date. A set of predefined values to query transfers:
|
Returns
List of cash transfers as Cash Transfer List object.
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is always sent. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
8.6. List Orders
Details
This API allows viewing historical orders (both working orders and orders in final state) on an account. User can always view orders on his own accounts, but can only view orders of other accounts if a special permission is set.
The API returns current state of the selected orders.
Since the API may return different results to different users, its results are not cached.
Resource
https://<host>/<path>/accounts/<account code>/orders/history
https://<host>/<path>/accounts/orders/history?accounts=<account codes>
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding)
-
account codes – comma-separated list of account codes (URL-encoded)
Method
GET, POST
(POST is supported to overcome the query URI length restriction in GET. Clients are expected to use POST in case complex queries are issued).
Request Data
Empty request.
Request Parameters
If several query parameters (in-status, of-type etc.) are provided, Boolean AND is assumed and orders are returned only if they match all of the filters.
limit |
Maximum number of orders to be returned by the query. Default value predefined in the historic.orders.max.count property in server side equals to 1000. If the provided value of the limit parameter is greater than the default value, then the default value is used. The response of the request includes the nextPageTransactionTime field to query next pack of orders using the transaction-to parameter described below. |
page |
If the request results in several "pages" of data returned, indicates the index of page in the result set to output data from. Index starts from 1. Even if the data is requested page by page using the page parameter, the limit parameter described above, or the default value predefined in the historic.orders.max.count property affects the result. The same way as for the limit parameter the response of the request may include the nextPageTransactionTime field to notify that there is at least one more pack of orders matching the query filter. |
page-size |
This parameter indicates the page size. It makes sense when it is expected to return result in several "pages" of data using the page parameter described above. If the page-size parameter isn’t set, but parameter page is set, then the default value (equal to 100) predefined in the historic.orders.page.size property in server side is used as page size. |
in-status |
Allows specifying filter for order statuses. Accepts comma-separated list of statuses (case insensitive). See Order Statuses. Multiple statuses are treated as "or" – an order that has any of these statuses is returned. If specified only COMPLETED status, last completed orders will be in response (order by completed time). |
of-type |
Allows specifying filter for order types. Accepts comma-separated list of types:
Multiple types are treated as "or" – an order that has any of these types is returned. |
issued-from issued-to |
These two parameters specify a filter for the order issue timestamp in UTC (see Times and Dates). Filter is inclusive. If only issued-from is specified, all orders from this time until now are returned. If only issued-to is specified, all orders from the very first order on an account until the specified time are returned. |
transaction-from transaction-to |
These two parameters specify a filter for the order last modification timestamp in UTC (see Times and Dates). Filter is inclusive. If only transaction-from is specified, all orders from this time until now are returned. If only transaction-to is specified, all orders from the very first order on an account until the specified time are returned. |
period |
A shortcut filter for order issue timestamp. Possible values are:
|
completed-from completed-to |
These two parameters specify a filter for the order completion timestamp in UTC (see Times and Dates). Filter is inclusive. If only completed-from is specified, all orders completed from this time until now are returned. If only completed-to is specified, all completed orders from the very first order on an account until the specified time are returned. |
at-least-version |
Sets a filter for the account version related to the last order update. If present, limits result set to include only orders which have the specified numeric version or greater. |
at-most-version |
Sets a filter for the account version related to the last order update. If present, limits result set to include only orders which have the specified numeric version or smaller. |
side |
Sets a filter for order operation:
|
with-client-id |
Sets a filter for the order unique ids assigned by client. Comma-separated list of ids is accepted. The list cannot be longer than 50 ids. |
with-order-id |
Sets a filter for the order unique numeric ids assigned by server when an order is initially placed. List of ids is accepted. The list cannot be longer than 50 ids. |
for-instrument |
Sets a filter for the order instrument (specified as comma-separated list of symbols) |
Returns
List of most recent orders (both completed and working) as Historic Order List object, sorted by transaction time in ascending order. Empty list is returned if no orders match the query filter.
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is not sent. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
-
Any of the filters (such as in-status) is in incorrect format or includes unknown entities.
Status code Error code Description 400 Bad Request
32
Incorrect request parameters (<request parameter that was incorrect>).
8.7. Account Metrics
Details
This API allows viewing current "metrics" for an account, such as equity, margin, PnL etc. User can always view metrics on his own accounts, but can only view metrics on other accounts if a special permission is set.
Since the API may return different results to different users, its results should not be cached.
Values in the API are fluent since they depend on current market data. So the client is either expected to poll the API to get current values or to make use of the notifications API (described in a separate document).
Resource
https://<host>/<path>/accounts/<account code>/metrics
https://<host>/<path>/accounts/metrics?accounts=<account codes>
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding)
-
account codes – comma-separated list of account codes (URL-encoded)
Method
GET
Request Data
Empty request.
Request Parameters
It is possible to include per-position metrics into result.
include-positions |
Boolean value. If true, result will include individual per-position metrics as Position Metrics objects, otherwise omitted. |
Returns
Account metrics for the account or a set of accounts as Account Metrics List object.
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is not sent. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
-
Any of the accounts not found or client is not permitted to access them.
Status code Error code Description 404 Not Found
2
Account(s) were not found: <comma separated list of not found accounts>.
8.8. Account Events
Details
This API allows viewing various 'events' regarding the account, such as liquidations or margin calls.
Since the API may return different results to different users, its results should not be cached.
Resource
https://<host>/<path>/accounts/<account code>/events
https://<host>/<path>/accounts/events?accounts=<account codes>
where:
-
account code is the unique code assigned to an account (URL-encoded, https://en.wikipedia.org/wiki/Percent-encoding)
-
account codes – comma-separated list of account codes (URL-encoded)
Method
GET
Request Data
Empty request.
Request Parameters
limit |
Maximum number of events to be displayed on query results page. Default value is configurable; if value more than default is provided, default value is used. |
start-from |
Indicates the starting index of event. Default value is 0. To use paging: set limit and start-from parameters. Ex. if limit=10, start-from=100 query results page will contain events from 101th to 110th |
of-type |
Filter for the event type (comma-separated). |
from-time to-time |
These two parameters specify a filter for the event timestamp in UTC (see Times and Dates). Filter is inclusive. If only from-time is specified, all events from this time until now are returned. If only to-time is specified, all events on an account until the specified time are returned. |
period |
A shortcut filter for event timestamp. Possible values are:
|
Returns
List of account events for the account or a set of accounts as Account Event List object.
Caching & ETag
Caching is prohibited for this resource. See Caching.
ETag header is sent. See Conditional Requests & Updates
Errors
See Common Errors for authentication-related errors.
9. Data Types
9.1. Single Order Request
orderCode |
For Place orders it is unique id assigned by the client. The id is expected to be unique among all orders on an account. See Client-originated Identifiers For modify orders order code can be either a client order id (assigned by the client during order placement) or an internal code assigned by the system ("action key" of the order chain). Server shall apply the following logic when selecting an order to modify:
String value. |
type |
Order type. Possible values:
Order type cannot be changed after the order is issued. The value must be omitted in ‘Replace’ requests except group requests, which may contain new orders in Replace requests. |
instrument |
Symbol of the instrument. The Instrument cannot be changed after the order is issued. In 'Modify' requests instrument must be the same as in the original order. |
quantity |
Initial quantity of the order in units (not in lots). See Numbers. Cannot be set together with cashQuantity. Cannot be negative. |
cashQuantity |
Initial cash (notional) quantity of the order. Cannot be set together with quantity. |
positionEffect |
Indicates expected position effect after a trade. Required for Equity/Option instruments trading. Not-required for Futures instruments trading. Possible values:
|
side |
Order operation. Possible values are :
|
limitPrice |
Limit order price per unit of quantity (use stopPrice for stop orders). Should be absent for Market and Stop orders. See Numbers. |
stopPrice |
Stop order price per unit of quantity (use limitPrice for limit orders). Should be absent for Market and Limit orders. See Numbers. |
stopPriceOffset |
Trailing stop orders price offset. Should be specified for TRAILING_STOP and TRAILING_STOP_LIMIT orders. See Price Offset. |
limitPriceOffset |
Trailing stop limit orders limit price offset. Could be specified for TRAILING_STOP_LIMIT orders. See Price Offset. |
tif |
Time in force (expiration time for the order). One of:
Default value depends on the platform configuration. Value are case-insensitive. |
expireDate |
Order expiration timestamp or date in UTC (see Times and Dates). Must be present if tif field is GTD. Otherwise, it must be omitted. |
checkBP |
Flag indicating if Buying power metrics validation for order should run. Default value is true |
checkRisk |
Flag indicating if Risk metrics validation for order should run. Default value is true |
9.2. Multileg Order Request
orderCode |
For Place orders it is unique id assigned by the client. The id is expected to be unique among all orders on an account. See Client-originated Identifiers For modify orders order code can be either a client order id (assigned by the client during order placement) or an internal code assigned by the system ("action key" of the order chain). Server shall apply the following logic when selecting an order to modify:
String value. |
type |
Order type. Possible values:
Order type cannot be changed after the order is issued. The value must be omitted in 'Replace' requests. |
quantity |
Initial quantity of the order in units (not in lots). See Numbers. |
limitPrice |
Limit order price per unit of quantity (use stopPrice for stop orders). Should be absent for Market and Stop orders. See Numbers. |
stopPrice |
Stop order price per unit of quantity (use limitPrice for limit orders). Should be absent for Market and Limit orders. See Numbers. |
stopPriceOffset |
Trailing stop orders price offset. Should be specified for TRAILING_STOP and TRAILING_STOP_LIMIT orders. See Price Offset. |
limitPriceOffset |
Trailing stop limit orders limit price offset. Could be specified for TRAILING_STOP_LIMIT orders. See Price Offset. |
legs |
List of Order Leg Request objects specifying order legs. |
tif |
Time in force (expiration time for the order). One of:
Default value depends on the platform configuration. Values are case-insensitive. |
expireDate |
Order expiration timestamp or date in UTC (see Times and Dates). Must be present if tif field is GTD. Otherwise, it must be omitted. |
9.3. Order Leg Request
instrument |
Instrument symbol of the leg. In 'Modify' requests symbol must be the same as in the original order leg. |
legRatio |
Ratio of the leg relative to the quantity of parent order. Floating point numeric value (see Numbers). Ratio of '1.0' means quantity of the leg instrument will be equal to the quantity of the order, '2.0' means the quantity will be two times larger etc. If omitted, ratio of '1.0' is assumed. |
positionEffect |
Indicates expected position effect after a trade. Required for Equity/Option instruments trading. Not-required for Futures instruments trading. Possible values:
|
side |
Order operation. Possible values are:
|
9.4. Order Group Request
Used to issue strategic order groups (e.g. IF-THEN or OCO one-cancels-other).
orders |
Set of orders in a group. Relations between orders is defined in a contingencyType field. Orders in group should have the same account. Orders can be either Single Order Request or Multileg Order Request. |
contingencyType |
One of the following values (case-insensitive):
|
ocoSubgroups |
This parameter may be used to combine then orders to OCO groups. Provide list of order code pairs here and these pairs will be combined to OCO groups. Example: [["orderCode1", "orderCode2"], ["orderCode3", "orderCode4"]]. All specified orders should be in request. Each group should contain exactly two orders. Order groups can’t intersect. |
9.5. Order
account |
Code of the account the order belongs to. See Numbers. |
orderId |
Internal numeric id of an order chain in the system. This value is assigned when an order is initially placed and does not change when an order is replaced or cancelled. See Numbers. |
orderCode |
Internal unique string code of an order chain in the system. This value is assigned when an order is initially placed and does not change when an order is replaced or cancelled. |
version |
Numeric version of the account to which last update of this order is related. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers. |
clientOrderId |
Unique order id assigned by the client during order placement. See Client-originated Identifiers. |
actionCode |
Internal unique code of the last order modification. String value. |
legCount |
Number of legs in the order. |
type |
Order type. Possible values:
|
instrument |
Symbol of the order’s instrument |
cashQuantity |
Cash (notional) order quantity. |
limitPrice |
Limit price of an order. |
stopPrice |
Stop price of an order. |
stopPriceOffset |
Trailing stop orders price offset. See Price Offset. |
limitPriceOffset |
Trailing stop limit orders limit price offset. See Price Offset. |
intermediateLimitPrice |
Intermediate limit price of Trailing Stop Limit order. Present only if real limit price is not known yet (set as offset from stop price and stop part is not triggered yet). |
intermediateStopPrice |
Intermediate stop price of Trailing Stop (Limit) order. Present only if real stop price is not known yet (not triggered). |
status |
Current state of the order. See Order Statuses. |
finalStatus |
Boolean value indicating if order is in final state. |
legs |
Statuses of all the legs as a list of Order Leg objects. |
side |
Order operation. Possible values are:
|
tif |
Time in force (expiration time for the order). One of:
|
expireDate |
Order expiration timestamp or date in UTC (see Times and Dates). The value is present if tif field is GTD. |
issueTime |
Timestamp in UTC when this order was accepted by the system. See Times and Dates. |
transactionTime |
Timestamp in UTC of the last order modification or fill. See Times and Dates. |
links |
List of the links between this order and other orders in its group as Order Link objects. Absent if the order is not a part of a group. Links calculated only for List Open Orders request. If parent order in group with parent or one of orders in OCO group is final, then links will be absent for such groups. |
executions |
List of all executions for this order. This includes order status changes, replaces, cancels and trades. Reports are ordered chronologically. See Execution. |
cashTransactions |
List of all cash transactions related to this order. Reports are ordered chronologically. See Cash Transaction. |
9.6. Order Response
orderId |
Internal numeric id of an order chain in the system. This value is assigned when an order is initially placed and does not change when an order is replaced or cancelled. See Numbers. |
updateOrderId |
Internal numeric id of an order. This value is assigned when an order is initially placed and updated when an order is replaced or cancelled. See Numbers. |
9.7. Validate Order Response
validationResult |
Total result of validation. Possible values:
|
failedValidationResults |
Array of Failed Validation Result objects. Present if validationResult differs from NOT_RESTRICTED. |
commissions |
Array of Commission objects. Commission value for each passed order. |
fees |
Array of Commission objects. Fee value for each passed order. |
9.8. Failed Validation Result
clientOrderId |
Client order code assigned to order. |
validationDescriptor |
Descriptor of failed validation. Full list of possible values is available here: https://confluence.in.devexperts.com/spaces/CT/pages/354980873/Pre-Trade+Validations (in Reject Reason column) |
validationDescriptorCode |
Number code of failed validation. Full list of possible code is available here: https://confluence.in.devexperts.com/spaces/CT/pages/354980873/Pre-Trade+Validations See Numbers. |
message |
Description of validation error in text format. |
9.9. Commission
clientOrderId |
Client order code assigned to order. |
value |
Commission (or Fee) value in Account currency. See Numbers. |
9.10. Order Leg
instrument |
Symbol of the leg’s instrument |
positionEffect |
Indicates expected position effect after a trade. Possible values (case-insensitive):
|
side |
Leg operation. Possible values are:
|
legRatio |
Ratio of the leg relative to the quantity of parent order (as specified during request). Equals to 1.0 for single leg orders. |
quantity |
Initial quantity of the order in units (not in lots) as specified in a "Place" request. |
filledQuantity |
Quantity filled so far in units (not in lots). If no fills took place, this field equals to 0.0. |
remainingQuantity |
Quantity available for further execution (in units). |
cashQuantity |
Initial cash (notional) quantity of order leg. |
filledCashQuantity |
Cash (notional) quantity filled so far. If no fills took place, this field equals to 0.0. |
remainingCashQuantity |
Cash (notional) quantity available for further execution. |
averagePrice |
Volume-weighted average price of all fills for this leg. The value is ‘0.0’ if there are no fills yet. |
9.11. Order Link
linkType |
One of the following values:
|
linkedOrder |
Internal unique string code of the linked order. Corresponds to orderCode field in the Order object. |
linkedClientOrderId |
Unique order id of the linked order. Corresponds to clientOrderId field in the Order object. |
9.12. Execution
account |
Code of the account the order belongs to. See Account Code. |
executionCode |
Unique string code of the execution. |
orderCode |
Internal unique string code of the corresponding order chain in the system. |
updateOrderId |
Internal numeric id of an updated order. |
version |
Numeric version of the account to which this execution relates. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers. |
clientOrderId |
Unique order id assigned by the client during order placement. See Client-originated Identifiers. |
actionCode |
Internal unique code of the last order modification. String value. |
instrument |
Symbol of the instrument |
status |
State of the order after this execution. See Order Statuses. |
finalStatus |
Boolean value indicating if order is in final state after this execution. |
filledQuantity |
Quantity filled so far in units (not in lots); signed value. If no fills took place, this field equals to 0.0. |
remainingQuantity |
Quantity available for further execution after this execution (in units). |
remainingCashQuantity |
Cash (notional) quantity available for further execution after this execution. Not zero only if order was created with cash quantity. |
lastQuantity |
The quantity of the fill, reported by the execution in units (not in lots); signed value. If the execution is not a fill, this field equals to 0.0. |
lastPrice |
For executions of TRADE execution type, price of the trade. Omitted for all other execution types. |
averagePrice |
Volume-weighted average price of all fills for this order up to (and including) this execution. The value equals to lastPrice if an order is filled with a single trade. |
transactionTime |
Timestamp of this execution in UTC. See Times and Dates. |
rejectReason |
If an order is rejected, this field contains a human-readable reject reason. In this case rejectCode field is also present. |
rejectCode |
Numeric code of an error in case of order rejections. Present (along with rejectReason) only if an order has been rejected. |
9.13. Cash Transaction
account |
Code of the account the transaction belongs to. See Account Code. |
transactionCode |
Unique string code of the transaction. |
orderCode |
Internal unique string code of the corresponding order chain in the system. Absent if transaction is not related to an order. |
tradeCode |
Unique string code of the trade. Corresponds to executionCode of a trade Execution. |
version |
Numeric version of the account to which this transaction relates. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers. |
clientOrderId |
Unique order id assigned by the client during order placement. See Client-originated Identifiers. |
type |
Transaction type. One of COMMISSION, FINANCING, DEPOSIT, WITHDRAWAL, COST, SETTLEMENT, EX_DIVIDEND, REBATE, MANUAL_CORRECTION, BUST, SERVICE_CHARGE, DIVIDEND, EXPIRATION, DELISTING, SPIN_OFF, RENAME, MERGER_ACQUISITION, SPLIT, EXERCISE, POSITION_UPDATE |
value |
Amount of the transaction in account’s base currency, signed (positive means profit, negative means loss). |
currency |
Currency of the transaction (see Currencies). |
transactionTime |
Timestamp of this transaction in UTC. See Times and Dates. |
createdTime |
Timestamp in UTC of this transaction request creation. It could take some time till actual transaction happens, exact transaction time is shown in |
9.14. Instrument List
instruments |
List of Instrument object. |
9.15. Instrument
type |
Instrument type as configured on the platform (e.g. INDEX). |
symbol |
Unique instrument symbol |
version |
Version of the instrument. Numeric value |
description |
Description of an instrument |
tradingStatus |
Instrument’s trading status. |
priceIncrement |
Specifies the minimum price difference by which the instrument’s price can be changed. It is represented as a String. For more detailed information, you can refer to the PriceIncrements. For example, if the Examples:
|
pipSize |
Size of 1 PIP in the system (e.g. 0.001), see Numbers. |
currency |
Trading currency of the instrument |
lotSize |
Lot size of the instrument |
multiplier |
Multiplier of the instrument |
underlying |
Symbol of the underlying instrument. Omitted if an instrument has no underlying. |
product |
Symbol of the product instrument (e.g. DJIA). |
optionDetails |
Details of an option instrument. If the instrument is not an option, this field is absent. See Option Details. |
expirationDetails |
Expiration details for derivative instruments (such as Futures or Options). See Expiration Details. |
settlementType |
For derivative instruments (such as Options and Futures) contains settlement type for the contract (either CASH or PHYSICAL). Absent for non-derivatives |
firstCurrency |
For Forex instruments, contains the first currency in pair (e.g. EUR for EUR/USD). Absent for all the other instrument types. |
tradingHours |
Trading calendar for this as a list of See Instrument Session objects. Sessions are order by time. |
currencyType |
For Currency instruments contains the currency type(FIAT, CRYPTO_CURRENCY or CRYPTO_TOKEN). Absent for all the other instrument types. |
marginRates |
Instrument’s margin rates in case of Stocks (also ETF, CFD-Stock, SB-Stock) in percents. Example: |
futuresMarginRequirements |
Instrument’s margin requirements in case of Futures (also CFD-Futures, SB-Futures). Simple dollar values, not percents. Example: |
additionalFields |
Additional fields which are set on the instruments |
9.16. Instrument Trading Schedule for the specific day or the current week
tradingHours |
Instrument’s trading hours specification according to dxFeed format. |
name |
The name of this schedule. |
timeZone |
The time zone in which this schedule is defined. |
sessions |
The list of sessions (The session of the day to represent trading schedule) that constitute a day. The day may be the current day, if schedule is requested for the current week, or it may be the specific day if schedule is requested for this day. The list is ordered according to natural order of sessions - how they occur one after another. |
day |
The day for which this schedule is defined. See The day to represent trading schedule. It is not null, if schedule is requested for the day. |
week |
The list of days (The day to represent trading schedule) of the current week. It is not null, if schedule is requested for the week. |
9.17. The session of the day to represent trading schedule
date |
The date of the day to which this session belongs. |
isTrading |
The flag indicating whether trading activity is allowed within this session. |
startTime |
The start time of this session (inclusive) defined in time zone of trading schedule. |
endTime |
The end time of this session (exclusive) defined in time zone of trading schedule. |
type |
The type of this session. One of:
|
9.18. The day to represent trading schedule
date |
The date of the day. |
isTrading |
The flag indicating whether trading activity is allowed within this day. |
isHoliday |
The flag indicating whether this day is an exchange holiday. |
isShort |
The flag indicating whether this day is a short day. |
startTime |
The start time of this day (inclusive) defined in time zone of trading schedule. |
endTime |
The end time of this day (exclusive) defined in time zone of trading schedule. |
dayOfWeek |
The day of the week, such as 'Tuesday'. |
9.19. Option Details
strike |
Strike of the option. See Numbers. |
optionSide |
Either CALL or PUT |
optionStyle |
Either EUROPEAN or AMERICAN |
sharesPerContract |
Number of shares per option contract. See Numbers. |
9.20. Expiration Details
maturityDate |
Instrument’s maturity date in month-year format. String value. |
expirationDate |
UTC date of the expiration of the contract. See Times and Dates. |
lastTradeDate |
UTC date of the last trading date of the contract. See Times and Dates. |
9.21. Instrument Session
weekDay |
UTC week date the event occurs (e.g. Monday, 23:00:00Z). See Times and Dates. |
eventType |
Either SESSION_OPEN or SESSION_CLOSE. |
9.22. User Details List
userDetails |
List of User Details objects. |
9.23. User Details
login |
Login of the user, string value. |
domain |
Domain of the user, string value. |
username |
Full username in 'login@domain' format. |
version |
Numeric version of the user. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers |
fullName |
Full name of the user |
accounts |
List of account details for all the accounts owned by the user. See Account Details. |
9.24. Account Details
owner |
Username of the account’s owner. Corresponds to 'username' field in the User Details object. |
account |
Code of the account. See Account Code. |
version |
Numeric version of the account. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers |
baseCurrency |
Base currency of the account |
registrationTime |
Timestamp in UTC when an account was registered. See Times and Dates. |
accountStatus |
Status of the account. One of FULL_TRADING, CLOSE_ONLY, NO_TRADING, TERMINATED, EXPIRED. |
9.25. Account Portfolio List
portfolios |
List of Account Portfolio objects. |
9.26. Account Portfolio
account |
Code of the account. See Account Code. |
version |
Numeric version of the account. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers |
balances |
Cash balances in various currencies as array of Balance objects. Zero balances are not included. |
positions |
Current positions on an account as array of Position objects. |
orders |
Current orders on an account as array of Order objects. |
9.27. Balance
account |
Code of the account the balance belongs to. See Account Code. |
version |
Numeric version of the account to which this balance relates. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers. |
value |
Balance in the given currency, signed. |
currency |
Currency of the balance (see Currencies). |
9.28. Position
account |
Code of the account. See Account Code. |
version |
Numeric version of the account. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers. |
symbol |
Symbol of the position’s instrument. |
quantity |
Current quantity of the position in units (not in lots); unsigned value. See Numbers. |
side |
Side of the position. Either BUY (long) or SELL (short). |
openTime |
Timestamp in UTC when this position was opened. See Times and Dates. |
openPrice |
Price at which the position was opened. See Numbers. |
lastUpdateTime |
Timestamp in UTC when this position was last updated. See Times and Dates. |
9.29. Cash Transfer
account |
Code of the account the transaction belongs to. See Account Code. |
version |
Numeric version of the account to which this transaction relates. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers. |
transferCode |
Unique code of a transfer. String value. Can be absent if this transfer is originated from a trade. |
comment |
Transfer comment (if present) |
transactionTime |
Transfer’s timestamp in UTC. See Times and Dates. |
createdTime |
Timestamp in UTC of this transaction request creation. It could take some time till actual transaction happens, exact transaction time is shown in |
cashTransactions |
List of all cash transactions related to this transfer. Reports are ordered chronologically. See Cash Transaction. |
9.30. Position List
positions |
List of Position objects. |
9.31. Order List
orders |
List of Order objects. |
9.32. Historic Order List
orders |
Sorted by transaction-time list of Order objects. |
nextPageTransactionTime |
If count of matched orders exceeds pre-configured on server side limit of orders, than nextPageTransactionTime field will be not empty. It is timestamp in UTC (see Times and Dates), which means transaction-time of first order, which was filtered from response. So, to make request to next 'page' of orders, parameter transaction-to should be set with value from nextPageTransactionTime field. |
9.33. Order Response List
orderResponses |
List of Order Response objects. |
9.34. Cash Transfer List
cashTransfers |
List of Cash Transfer objects. |
9.35. Account Metrics List
metrics |
List of Account Metrics objects. |
9.36. Account Metrics
account |
Code of the account. See Account Code. |
version |
Numeric version of the account. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers. |
equity |
Balance + SUM(Market Value across positions) |
balance |
Total balance of the account in account’s base currency |
availableFunds |
The "available funds" of the account in the account’s base currency. |
availableBalanceForWithdrawal |
Amount of money (in account’s base currency) available for withdrawal. |
openPl |
Open (Unrealized) Profit/Loss. |
initialMargin |
Initial margin |
maintenanceMargin |
Maintenance margin |
maintenanceExcess |
Excess of maintenance margin |
dayClosedPl |
Day Realized PL |
netLiquidation |
Net Liquidation value |
openPositionsCount |
Number of open (non-zero quantity) positions on tradable instruments |
openOrdersCount |
Number of order chains in non-final state |
autoLiquidationPeak |
The portfolio peak that defines the Max Drawdown auto liquidation threshold.
The calculation formula depends on Max Drawdown mode. |
maxDrawdown |
The portfolio peak that defines the Max Drawdown auto liquidation threshold.
The calculation formula depends on Max Drawdown mode. |
drawdownMode |
Won’t be present if Max Drawdown validation is disabled. |
trailingDrawdownDelta |
Trailing drawdown delta |
staticMaxDrawdown |
A fixed drawdown threshold that does not change with the portfolio’s performance. |
positions |
If specified during request, contains a list of individual position metrics as Position Metrics objects, otherwise omitted. |
9.37. Position Metrics
version |
Numeric version of the account. Client can use this value to find out which of the updates is more recent (its version is greater). See Numbers. |
symbol |
Symbol of the position’s instrument. |
quantity |
Current quantity of the position in units (not in lots); signed value. See Numbers. |
openPl |
Floating profit-loss in account’s base currency |
initialMargin |
Initial margin in account’s base currency |
maintenanceMargin |
Maintenance margin in account’s base currency |
markPrice |
Mark price |
dayClosedPl |
Realized PL for the current business day for the position |
avgOpenPrice |
Average price for the position |
9.38. Account Event List
accountEvents |
List of Account Event objects. |
9.39. Account Event
account |
Code of the account. See Account Code. |
eventType |
One of the following values:
|
reason |
Account event reason message |