inconsistency with get_history lseg api endpoint

valstar
valstar Explorer
edited March 26 in Eikon Data APIs

I'm currently migrating a workflow from the legacy Eikon Python API to the new LSEG Data (RD) API, and I’ve encountered a couple of points that require clarification. In the Eikon API, I was using the get_timeseries() function with fields='CLOSE' to retrieve historical Euribor data for the following instruments:

  • EURIBORSWD=
  • EURIBOR1MD=
  • EURIBOR3MD=
  • EURIBOR6MD=
  • EURIBOR1YD=

Upon switching to the LSEG Data API, I found that the CLOSE field is not supported for these instruments when using get_history(). After some testing, I noticed that the FIXING_1 field appears to return the same values as CLOSE did previously. Could you please confirm whether FIXING_1 is the appropriate equivalent to CLOSE for these RICs in the RD API?

Additionally, I observed that get_history() does not include the end date in the returned results, unlike get_timeseries() in the Eikon API, which returns data for both the start and end dates. Is this exclusion of the end date expected behavior in the LSEG Data API, or is there a recommended way to include it? Sometimes get_history() the startdate, and sometimes it doesn’t (running the exact same query), this makes it difficult to work with.

I’ve attached an image showing the output from both APIs side by side, including the function calls and the resulting values for reference, RICS contains the instruments listed above.

image-6b32feeda063d-38c4.png

Best Answer

  • nick.zincone
    nick.zincone admin
    edited March 27 Answer ✓

    Hi @valstar

    The legacy historical service uses a consolidated reference for each asset, that is whether the asset is a currency, fixed income or equity, the 'CLOSE' will be used. But this service also limits the number of fields available for historical data. The new historical service, today, uses more accurate references to the fields so the concept of close for the different assets will be specified differently, which you have observed.

    Regarding the date range, the historical service does have a parameter called "SummaryTimestampLabel", which will have different default behavior depending on whether it is interday vs intraday. For example here is the command you can use which will return the correct data based on the specified date range:

    image.png

    In this case, for your daily (interday) request, the default is 'endPeriod':

    image.png

    So, you will have to overwrite the default by specifying 'startPeriod'.

Answers

  • @valstar Thanks for your question - so I can replicate your issue and am checking with the dev team:

    ld.get_history(
    universe=['EURIBORSWD='],
    interval="daily",
    start="2025-03-16",
    end="2025-03-24",
    )

    image.png

    I will report back asap. For now just request 1 day earlier as a workaround. Apologies for this. I hope this can help.