Disabled the security for operation for the API: Retrieve System Status
For the field "fixedTerm" removed the property of multipleOf. The value of multipleOf property was automatically overwritten as a scientific value 1e-7 which cause deserialization error in some programming language. To avoid this situation, the property has been removed and in the description it is indicated as maximum 7 digits is supported after decimal.
The pattern for deliveryStartDateTime and deliveryEndDateTime is updated for the API: Submit/Modify Scalable Complex Orders
The optional query parameter include[] was displayed as an array[string] in the portal previously. This is corrected to display the type: string and removed the enum type usage as this lead to the incorrect display of type: array[string] in the portal. Explicitly mentioned in the description what is the allowed value.
v1.5.0
New API: Retrieve system status
v1.4.1
Harmonization of data types related to order Ids* used in requests path parameter:
linearOrderId, blockOrderId & scalableComplexOrderId, changed to integer with format int64,
in order to align with the data type change of the field orderId included in API request & response under version v1.4.0
v1.4.0
Data type of "blockCodePRM" field is changed from integer to integer with format int64. This change is applicable for all block order related API end points in which blockCodePRM value is included.
Removed the "required" property for the objects linearOrderResults, blockOrderResults and scalableComplexOrderResults. These objects are optional.
Impacted API end points: Retrieve Aggregated Results
Removed the "required" property for the objects "details" as part of schema definitions: "Warnings" & "Errors". This object is made is optional because "details" can be null. If the property "required" is selected then during client code generation (ex: in C#) "null" possibility is not interpreted well creating json deserialization issue. By removing the "required" property this behavior is fixed.
Impacted API end points: Retrieve Aggregated Results
Added the property minItem = 2 as part of the object curvePoints
Data type of "orderId" changed from integer to integer with format int64
Impacted API end points:
Retrieve Linear Order Results
Retrieve Block Order Results
Retrieve Scalable Complex Order Results
Retrieve Trade Results
Data type of "tradeId" & "orderPeriodId" changed from integer to integer with format int64
Impacted API end points: Retrieve Trade Results
Include the missing "optional" schema related to "orderBookStatistics". This object is only valid if the optional query parameter include[]=order-book-statistics is used.
Impacted API end points: Retrieve Auction Session Information
Include the missing field "settlementMemberName"
Impacted API end points:
Retrieve Portfolio Information
Retrieve Portfolios
Include optional query parameters participant & settlement-member
Impacted API end points:
Retrieve Portfolios
Add an explicit description of the limitation of not able to define a empty array which would result in _data[] in case of warning included in the response.
For the end points: Retrieve Linear Order & Retrieve Scalable Complex Order, the schema is updated to have an array object. Previously it was referring to a single object.
Update element "pagination" from array object to single object
Impacted API end points:
Retrieve Logs
Include update the schema model as part of HTTP status code 400. For the below listed impacted end points, there is a specific situation which will lead to return an array of object instead of an array of string for the field "details". To avoid deserialization issue, a dedicated schema is created and linked using $ref for the HTTP status code 400 to respect the array of object format for the field "details"
Impacted API end points:
Submit/Modify Linear Orders
Submit/Modify Block Orders
Submit/Modify Scalable Complex Orders
v1.3.0
Release date: 25-02-2025
Change details:
Include new optional field "clientOrderId"
Impacted API end points:
Retrieve Linear Orders, Submit/Modify Linear Orders, Retrieve Linear Order, Delete All Linear Orders
(Applicable for Block Orders & Scalable Complex Orders)
Include new field "resultStatus"
Impacted API end points:
Retrieve Auction Sessions, Retrieve Auction Session Information
Include new field "submittedVolume"
Impacted API end points:
Retrieve Block Order Results
Include new optional query param: “participant”
Impacted API end points:
Retrieve Linear Order Results, Retrieve Block Order Results, Retrieve Scalable Complex Order Results
New API end point: Retrieve Market Result Report (CSV) to retrieve market result file
Update of API response content from raw XML to JSON format
Impacted API end points:
Retrieve Trade Report (XML)
Include additional properties such as minLength, maxLength, minimum, maximum, pattern etc in the order management related API end points (GET, POST, DELETE)
For the below API end points, the object “blockPeriods” were defined in each API resource individually. To avoid high maintenance and avoid generation of classes with same objects and same names which are same in principle and functional perspective, a common model is used and linked these API resources using the keyword $ref
Impacted API end points:
Retrieve Block Orders, Submit/Modify Block Orders, Retrieve Block Order, Delete Block Order, Delete Block Order By BlockCodePRM, Delete All Block Orders
v1.2.0
Release date: 14-02-2025
Change details:
Data type of the query parameter, “duration” [Used in the API resources like Retrieve Linear Order, Retrieve Block Order etc] is updated from number to integer.
Previous version of the API documentation indicated that "_notification" is an array of WarningNotification. In the system, it is not actually an array but only the warnings attribute is an array. "_notification" is a single object.
In the block order related API resources, it was indicated that “submissionSequenceNumber” is mandatory. Even though this field is always returned in the API response block order resources; the value of this field can be “null”. (in case of C01 block). API document is updated to indicate the field “submissionSequenceNumber” is optional.
Data type of "orderId" field is changed from integer to integer
For Scalable complex orders, additional properties minimum & maximum for "orderId" is removed
For API: Retrieve FX rate, format of query parameter “date” changed from date-time to date
For DELETE linear order and scalable complex order end points, previously it was indicated that data is returned as a single object. API document is updated to correctly indicate that data is returned as an array.
_data element in swagger was not tagged as “mandatory” element. As per system design, "_data" element is always returned in the response even if it is with an empty array/object. In the API documentation, "_data" element is tagged as “mandatory”
For the below API end points, the objects curve & curve points were defined in each API resource individually. To avoid high maintenance and avoid generation of classes with same objects and same names which are same in principle and functional perspective, a common model is used and linked these API resources using the keyword $ref
Impacted API end points:
Retrieve Linear Orders, Submit/Modify Linear Orders, Retrieve Linear Order, Delete Linear Order, Delete All Linear Orders
In the API documentation, the typo mistake in the field name "periodsResults" is corrected. Correct field name is "periodResults"
In the API documentation, added the missing "_notification" object as part of API: Connect response (with HTTP status 200)
In the API documentation, for API: Retrieve Block Order Results, "status" enum values were indicated as Rejected and Accepted. Correct values are Rejected and Executed are indicated
v1.1.0
Release date: 24-12-2024
Change details:
All the API responses are updated to have one single schema instead of combining several schemas using anyOf or oneOf keywords
Fixed the issue of generating the empty classes using the Generate code feature
Aligned the client code names same as the API resource functional names used in API documentation (wherever possible) for better readability
Aligned the names of the API resources that appears in the web portal URL with the functional names of the each API resources