@vinaya.shetty,

In a nutshell

As I see, what you seek is 2 things:

• A multi instrument request, but not all instruments in the same time range. This is possible.
• A request for a point in time. This does not exist.

In more detail

There is no API call in TRTH for extracting a single price for a specific point in time, be it for one or more instruments.

It is possible to make a query (for this use case it would be a Tick History Time and Sales) for multiple instruments, each with its own date/time range. It is not possible to specify a point in time; it must be a range (i.e. use a start and end time). This is described on page 6 of the TRTH 12.1 Release notes.

Here is a sample query illustrating the required syntax:

{
  "ExtractionRequest": {
    "@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.TickHistoryTimeAndSalesExtractionRequest",
    "ContentFieldNames": [ "Quote - Bid Size", "Quote - Bid Price", "Quote - Ask Size", "Quote - Ask Price" ],
    "IdentifierList": {
      "@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.InstrumentIdentifierList",  
      "InstrumentIdentifiers": [
        { "@odata.type": "#ThomsonReuters.Dss.Api.Content.HistoricalInstrumentIdentifier",
          "Identifier": "VOD.L", "IdentifierType": "Ric",
          "RangeStart": "2018-10-25T10:08:53.000Z", "RangeEnd": "2018-10-25T10:08:54.000Z" },
        { "@odata.type": "#ThomsonReuters.Dss.Api.Content.HistoricalInstrumentIdentifier",
          "Identifier": "CARR.PA", "IdentifierType": "Ric",
          "RangeStart": "2018-10-26T10:09:52.000Z", "RangeEnd": "2018-10-26T10:09:55.000Z" },
        { "@odata.type": "#ThomsonReuters.Dss.Api.Content.HistoricalInstrumentIdentifier",
          "Identifier": "ALVG.DE", "IdentifierType": "Ric",
          "RangeStart": "2018-10-24T14:21:56.000Z", "RangeEnd": "2018-10-24T14:21:57.000Z" }
      ],
      "ValidationOptions": { "AllowHistoricalInstruments": true },
      "UseUserPreferencesForValidationOptions" : false
    },
    "Condition": {
      "MessageTimeStampIn": "LocalExchangeTime",
      "TimeRangeMode": "Inclusive",
      "ApplyCorrectionsAndCancellations": false,
      "ReportDateRangeType": "PerIdentifier",
      "DisplaySourceRIC": true
    }
  }
}

Response:

#RIC,Alias Underlying RIC,Domain,Date-Time,Type,Bid Price,Bid Size,Ask Price,Ask Size
ALVG.DE,,Market Price,2018-10-24T16:21:56.875440171+02,Quote,184.42,75,184.48,333
ALVG.DE,,Market Price,2018-10-24T16:21:56.875440171+02,Quote,184.42,176,184.48,333
ALVG.DE,,Market Price,2018-10-24T16:21:56.999746071+02,Quote,184.42,226,184.48,333
VOD.L,,Market Price,2018-10-25T11:08:53.208974278+01,Quote,145.9,8122,145.94,2143

Note: the extraction will only return the data available in the specified range. If the range is very short or the instrument illiquid, the result set might be empty (as is the case for CARR.PA in the above example). A trade off must therefore be found between the range size (the larger, the greater the probability of receiving a result) and the volume of data you must treat after retrieval, taking instrument volatility into account.

Consequence: you must make your own algorithm and code to select from the results the data closest to the point in time you are interested in.

Important caveat: this feature is currently in EAP (Early Access Program). If you are not entitled to it, you will receive an error message: "Not authorized to perform extraction with ReportDateRangeType set to PerIdentifer.". If you are interested in this feature, contact your account manager.

Hi @Christiaan Meihsl, I have gone through the details on Release Notes and arrived at below Time and Sales code for Report on Multiple Instruments, With a Different Date Range for Each

{ "ExtractionRequest": {
 "@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.TickHistoryTimeAndSalesExtractionRequest",
 "ContentFieldNames": [
   "Quote - Bid Size", "Quote - Bid Price", "Quote - Ask Size", "Quote - Ask Price"
 ],
 "IdentifierList": {
  "@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.InstrumentIdentifierList",
  "InstrumentIdentifiers": [
   { "Identifier": "VOD.L", "IdentifierType": "Ric",
   "ValidationOptions": { "AllowHistoricalInstruments": true },
   "UseUserPreferencesForValidationOptions" : false,
   "Condition": {
    "MessageTimeStampIn" : "LocalExchangeTime",
    "TimeRangeMode": "Inclusive",
    "ReportDateRangeType": "PerIdentifier",
    "RangeStart": "2018-10-25T10:00:00.000",
    "RangeEnd": "2018-10-25T15:00:00.000",
    "DateRangeTimeZone" : "Local Exchange Time Zone"
   },
   { "Identifier": "AAPL.O", "IdentifierType": "Ric"
   "ValidationOptions": { "AllowHistoricalInstruments": true },
   "UseUserPreferencesForValidationOptions" : false }},
   "Condition": {
    "MessageTimeStampIn" : "LocalExchangeTime",
    "TimeRangeMode": "Inclusive",
    "ReportDateRangeType": "PerIdentifier",
    "RangeStart": "2018-09-25T10:00:00.000",
    "RangeEnd": "2018-09-25T15:00:00.000",
    "DateRangeTimeZone" : "Local Exchange Time Zone"
  }
 }
}

But I am receiving a bad string,

@Christiaan Meihsl @zoya.farberov May I know if the ReportDateRangeType set to PerIdentifer feature is live now? If not may I know when are we targetting to push this to PROD?

I have tested this now and observed the same error message:

{

"error": {

"message": "Not authorized to perform extraction with ReportDateRangeType set to PerIdentifer."

}

}

Hello @Beera.Rajesh,

Please see current reference for TickHistoryTimeAndSalesExtractionRequest,

Condition remains per Request, not per InstrumentIdentifier:

Do not believe PerIdentifier is implemented in the way that you suggest. I also do not see it in Summary as part of "Possible Values".

Personally, I think the currently implemented submitting different date ranges and separate requests is cleaner, as dates in result alight, and less error prone.

From the internal RTH 2021 plans, I do not see it as planned.

Therefore, I would continue requesting different date ranges as separate requests.

---

As questions with accepted correct answers have low visibility for community members and are not actively monitored by moderators, I would suggest in the future to ask new questions that are related to them as separate new questions, and include the link to the original answered question within the new question.

Hope this helps