HistoricalCriteriaSearch how to limit result from the request

Hi,
I have read the documentation but still looking for answers.
I need to limit the result, by example for below POST request it takes 439680 ms to a size of 9.86 MB.
POST /RestApi/v1/Search/HistoricalCriteriaSearch HTTP/1.1
Host: select.datascopeapi.extranet.reuters.biz
Content-Type: application/json
Authorization: Basic OTAxODEwMDpMYWgzNjcwIWY4RDU=
cache-control: no-cache
Postman-Token: 0532c3cc-e48d-4244-a8bd-f033b4ced528
{
"Request": {
"RicPattern": "SEK",
"Range": {
"Start": "2018-11-20T00:00:00.000Z",
"End": "2018-11-21T00:00:00.000Z" } }}
Results as:
"Identifier": "#####T#SEKAB6SFM"
And a lot more noise.
I wish to specify additional parameters in the request such as: "Status" and "IdentifierType". Or similar in order to narrow the result to less noise.
Also I don't understand what "Start" in "Range" is expected to provide? My above request returns by example:
"FirstDate": "2011-06-10T00:00:00.000Z",
"LastDate": "2018-11-27T00:00:00.000Z",
Even if I specified 2018-11-20 to 2018-11-21?
Kind regards,
Johan
Best Answer
-
Your request
It specifies only 2 criteria:
RicPattern - Return all RIC names that contain the string "SEK".
Range - Return all instruments that were active during that time period.
So your query returns all instruments that were active on 20th November 2018, where the RIC contains "SEK". That will deliver many results, hence the long extraction time you observe.
The returned FirstDate / LastDate are the first / last dates where each instrument was active.
Filtering results
You cannot define:
- The IdentifierType. But results will only contain "Ric" and "ChainRic", nothing else.
- The instrument "Status". That said, you will only receive instruments that were active in the range you specified. I believe (not 100% sure, I'm not a data specialist) that the returned Status should always be "Valid".
That said, there is a whole set of criteria you can use to limit results:
RicPattern, BondTypeCodes, ContributorIds, CountryCodes, CurrencyCodes, DomainCodes, ExchangeCodes, FutureMonthCodes, InstrumentTypeCodes, OptionMonthCodes, OptionTypeCodes, CouponRate, StrikePrice, ExpiryDate, MaturityDate.
A few comments on these filters:
- InstrumentTypeCodes can limit results to specific types, like Forex Cash Options (by setting InstrumentTypeCodes to value 211) for instance.
- CurencyCodes uses a number for each currency, not a string. You can find the numbers using a GET to endpoint /RestApi/v1/Search/GetHistoricalCurrencies. For SEK the number is 752.
- ExchangeCodes behaves in a similar way, you can find the numbers using a GET to endpoint /RestApi/v1/Search/GetHistoricalExchanges.
Note on the RicPattern regular expression
As per this thread, historical criteria search currently supports only the following regular expression patterns:
- Begin with: ^ e.g. ^IBM // Begin with ‘IBM’
- End with: $ e.g. =RR$ // End with ‘=RR’
- Contain: string e.g. EUR // Contain ‘EUR’
You can escape special characters using a double slash, i.e. "\\"
Example: If you want to use a "." as a literal dot (and not as "any character"), then you need to escape it with , like in "\\.N$" to select any RIC that ends with ".N".
Example query
Retrieve Energy Market Statistics instruments containing "RED" in the RIC, in Danish or Swedish krona:
{
"Request": {
"RicPattern": "RED",
"BondTypeCodes": null,
"ContributorIds": null,
"CountryCodes": null,
"CurrencyCodes": [ "208", "752" ],
"DomainCodes": null,
"ExchangeCodes": null,
"FutureMonthCodes": null,
"InstrumentTypeCodes": [ "133" ],
"OptionMonthCodes": null,
"OptionTypeCodes": null,
"CouponRate": null,
"StrikePrice": null,
"ExpiryDate": null,
"MaturityDate": null,
"Range": {
"Start": "2018-11-20T00:00:00.000Z",
"End": "2018-11-21T00:00:00.000Z"
}
}
}For more information
The TRTH REST API Tutorial 14 and the REST API Reference tree provide information you might find useful.
Hope this helps.
0
Answers
-
Thank you Christiaan for the extensive answer,
I will try write a logic using regular expressions and share result in case of success, for my specific use case. Which is big lists of trades with none- to limited static data in first instance. Where we want to avoid develop too much logic towards internal golden source copies.
Kind regards,
Johan
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 687 Datastream
- 1.4K DSS
- 621 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 254 ETA
- 557 WebSocket API
- 38 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 276 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 669 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 193 TREP Infrastructure
- 229 TRKD
- 917 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 90 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛