This issue is isolated to the TimeSeries_UDF_endpoint. There is absolutely no issue with the get_data endpoint requested through eikon.get_data

File ~\AppData\Local\anaconda3\Lib\site-packages\eikon\time_series.py:182 in get_timeseries

    ts_result = eikon.json_requests.send_json_request(TimeSeries_UDF_endpoint, payload, debug=debug)

  File ~\AppData\Local\anaconda3\Lib\site-packages\eikon\json_requests.py:134 in send_json_request

    raise EikonError(eikon_err.code, eikon_err.message)

EikonError: Error code 2504 | UDF Core request failed. Gateway Time-out

Could you point me to:

1. How to request API credentials (client ID / secret)
2. Minimum Eikon subscription required
3. Whether chatroom message subscriptions (not just 1-on-1) are supported

For example, by setting Japanese names in firstname and lastname, and English names in customfields, is it possible to influence the search results?

Post:

LSEG Identity Gateway | LSEG

We are working with multiple LSEG services and we are using EMA to manage them all.
We create multiple connections/sessions/OmmConsumers that connect to the same order of endpoints/Channels. We connect using an access token.

We were told that when connecting, we should send the UUID as well such that the routing for the multiple connections end up at the same ADS/their backend server.

But here is the questions as we were told multiple things from multiple directions.

We are sending the UUID as "setPosition" when creating the OmmConsumerConfig, and we send it in the format of "127.0.0.1/<UUID>", where "<UUID>" is the UUID which we take from a JWT when an access token is generated, but we were also told to send the UUID in "tunnelingObjectName", directly without any extra information.

Is that necessary/correct?

If it is, is it enough to only set tunnelingObjectName and position? How exactly should they be set for both properties, so that we know they are correctly sent and parsed?

Do we also have to set other properties alongside them?

Thanks

We are trying to retrieve all instruments (both active and inactive) per stock exchange (e.g., XOSL - Oslo Stock Exchange) in DSS (Datascope Select). However, it seems that the number of instruments is restricted to a maximum of 5,000, as shown in the attached image, and we need to retrieve the full list beyond this limit.

If a REST API-based solution is required, we are open to exploring that as well. Any suggestions or guidance would be greatly appreciated.

The goal is to get dividend data of these instruments. But I suppose we need to list the instruments of our interests.

Thank you in advance for your help!

I have wrote codes below to get USDSROIS quotes data and latest trade price.
import lseg.data as ld
def on_data(data, instrument, stream_obj):
print(data)
stream = ld.open_pricing_stream(
universe=['USDSROIS1WZ=R',
'USDSROIS2W=',
'USDSROIS3W=',
'USDSROIS1M=',
'USDSROIS2M=',
'USDSROIS3M=',
'USDSROIS4M=',
'USDSROIS5M=',
'USDSROIS6M=',
'USDSROIS9M=',
'USDSROIS1Y='],
fields=['DSPLY_NAME','BID', 'ASK', 'CF_CLOSE','CF_TIME','CF_LAST','CF_TICK','TR.CLOSEPRICE'],
on_data=on_data
)
But as I've seen, last trade price don't show for many symbols. Here is an example.
BID ASK CF_TIME
USDSROIS9M= 3.7842 3.8042 09:23:23

How to solve this problem?
Furthermore, can I get USD Sofr OIS Curve by open_pricing_stream or other method?

the ric is DE10YT=RR

Is there an API that would allow me to programmatically download company filings from Workspace and access the full text of the filing documents for processing in Python?

My use case is to run keyword-based searches (regex / NLP) across filings for multiple companies and flag documents that match predefined criteria. Ideally, I’d like to automate both the retrieval of the filings and the ingestion of their text content.
Many thanks
Bart

I also tried to get the data for a few SEDOLs to RIC using the similar code:

response = symbol_conversion.Definition(    symbols=['BD4D737','BLD2CY7','BGS21V7','B296314','B59HM77','B9J4K16','BRJFXN8','6357852','BLGTZK2','B00SV00','6776703','6929325','BD1F0W6','BFMZJ55','BYV98H6','BLD1SB3','B3X0F91','B15F5K1','6439567','6121176','B44P7W9','BZ7NDP2','6397825','B02FBC1','6586872','6168838','6317072','BYVQ673','BDRY2P4','BMQ69T7','6073556','BD5CND5','BR1R6P5','BNHBMG6','BFYTT00','BLD9KX3','BK6YZP5','BP41ZD1','BF06LG5','6181482','B61TX08','BH0VXF7','BYVRFP7','B8F2T65','BH4TZ73','BD5CPN9','6196077','B01JCK9','BD5CPP1','BMZ14N2','BBPD5F0','B39GMS1','BFSQNZ0','B1XDJC7','6321954','BNYK8H9','BK1K3N2','BTF4P59','B1L3WW0','B2RJYH8','BZ04KX9','B633D97','B7MD0V6','6105738','B01B1L9','BMH5F39','BFB4S78','0','B3MPN59','6903556','B29MKF5','B1Z7648','BZ0D252','BD9GZX7','BD5M1Z3','BN74BB3','BPVGW16','BQL7RK0','B755514','BP3R8G4','BNCDW78','6560995','6782045','6162692','B5MDP39','BVVPXP6','BD5CHT9','BG8HFQ5','6803225','BNK9Q76','6742340','B4Q4CJ6','B3ZVDV0','BYP9J68','6045180','BPFGJZ5','BKRD2S3','BD5CJ26','BYZJV17','BCDBKF8','B297KM7','BP3R2Q2','BMD2L36','BK71CZ4','BMGBJV4','BK5DF97','BMQDPD4','BN320D6','BJQWRW3','BN936W4','6579010','B296ZH4','BS9BY18','6743956','BYVDW43','B133G60','BLC7TD1','6015644','BNR4N95','BNV5PM1','BP98612','BMQDPG7','BPLGW83','BD5CFP1','BNM7KH6','BRHXHZ4','BN19HM7','B1DN3X6','B44ZV94','B54DPL5','B890GY2','B3TYW07','BMTCVV8','B1P1JS5','B3ZNGT5','6000305','BHQPST2','B4N6NB4','6803247','6192150','6193766','B56KLY9','BK8JKG4','6333937','6092357','6856995','6193681','BF09MJ4','6444497','6465874','BKL9QV8','6555087','B1WMLF2','B2NDF82','6039558','6317339','BLLHKZ1','BJQ2P07','BH0W286','B01RQM3','B61X7R5','BHB1WW6','B4YWZT3','BQT2R07','B128WL3','BD87BS8','B00HR98','BF06TZ0','BN46YN5','6121563','B4Z9XF5','B1GKL41','6253767','6139362','BPFJHC7','BF0VND1','BFT7KB7','6368520','BK1N461','2781648','BMH4TB2','6171900','BSZ2BY7','6101026','B40MFF3','BD6FGZ6','B96RL59','6652881','BS4DBX0','BF2B3K6','BN8ZT55','BWCGVX9','BNQNGS3','BNRNLH6','B1LDTB8','B0YJJ27','B1L9PJ6','BZC0W28','BF37466','BKMFNP8','BK7GN01','B19HGC2','6404996','B07LTC0','B1WT818','2398822','BD6F8V6','B1R3S15','BWFGD63','6099938','6437624','BNHWKG5','BYT56K5','BRC0Q31','B1BL581','BNVXB61','B0YVBS3','B233LP1','B233HS6','B00L819','B7JW351','6120270','6305442','6653334','6366999','B4LD3M8','B9DG2Q7','BL4P3Q4','6651048','6727121','BFY6H41','B80NSQ6','BFZ8G27','B1F1R58','B00D9M3','BC1J0F4','6214195','6202178','6291767','B4KWQ72','BDHBG75','B232R27','B7T5KQ0','6449544','BWB95X7','6212564','6529792','6515434','BD95QN1','BZ60JT0','6896849','6155937','B01LXY6','B00VS64','B01T146','6434562','6155250','6397502','B00GJN3','BF07GJ6','B94K2F7','6315054','B42MSJ6','BLF9YV7','B3F2324','BNGJH11','6316875','BNSP8W5','6180230','B7D29Z9','BYXYVM5','6450267','BS7JCP4','6249584','6988155','6346913','6693233','BD85VX7','B78CP12','B142NG5','BDFM6W5','6493585','B088VB3','6609304','BFN65V5','6113429','BPK3M63','B7RLFB0','BLRL853','B2NRDM4','6736213','BQ13Z04','B2NRDY6','BNDMZJ7','B92RW83','B0XNCB0','BM8X3Q1','B7WJ188','B2927P4','BPYD720','BNZKT97','B1G16Z0','6094825','B1VT035','BXC7XC2','B23DMQ9','BF249P2','BL9YQK1','B0DJQ38','B5ZXWL3','6186540','6475538','BQY2KF8','6160384','BSZLN15','6874027','BJYRGH8','B58J1S8','6729503','B033QQ3','B56VQB4','B5SG8Y4','B97NLT0','B4VYX10','6432566','6715557','B00VD14','6316121','6439620','B8DJMF8','6451668','6372480','6577081','6599676','B43HJN1','BK0MPZ5','B43MWS2','2113382','6889106','6716538','6290355','B0P6L87','BJDS3L5','B734XQ4','B05PZJ3','B15F664','6887887','BXCZ9P1','BNG18T2','BF1QN02','6554675','6554697','BDVKB40','6589473','BD215T5','BRS7681','BMY0YX0','BVFMFG8','B6TCNK9','BMC4B77','BMWS3X9','B23DBK6','2257019','2463247','2588184','BP3RNW5','BDSFW67','B16GK97','BFMST43','B1XLCQ6','6110497','6534837','BVBH523','BPSMGV5','BTDBK35','6717456','BL6HQ81','BS2KWR4','BQXH1K6','B24FZ32','BRZWZC6','B0RJCG9','BKC9L01','B3N0H17','B3PZ2V5','BPGKFW5','BYYFJV2','BSFTLJ3','BT14FF3','BYNKP98','BMX09H0','BN7RMD1','BGMHP50','6002895','B1L2RC2','BSF1LV1','BKSBTW9','B56HH42','B953PM3','BSN62Q0','B1VRCG6','6725299','BN6HJY2','BYYMZN7','BHR0FS4','B58YWF7','B1KYHF2','B4Q1532','B4JSTL6','B0190C7','BP5JGC0','6100454','B07Y2F3','B15T3F4','6543877','6687184','6048156','BFNBJ41','B01C1P6','BRBXGH5','6454861','BGXQL36','6505316','BPF0559','6451055','6984959','B622C10','BDVLJ72','BD6GC06','6248332','B4NYSN5','B1P1GJ5','6771720','BM9Q3H0','B2QQP88','BK5CYG4','BKPN4N4','BQ95T22','6744722','BNXK2C3','BSDZ375','6320832','B28SKW1','6283601','6421928','6254083','BS7HXD3','B1359J0','BLZGSM7','B0166H5','BXC7WG9','BGH17Y0','BD41Z93','BD72GW3','BMY5866','B15XDH8','B64FX58','B1GJZD5','BS3KM73','BQTPLM6','BSJ50P6','6518217','6739739','BF4NQP6','6549013','BVYDL20','BJP0B04','B4YX1N2','B3ZPCV5','B00FYK2','6254511','BV8DR17','B1LJQC6','6638115','6770556','B5VN637','B5YGG00','B52J816','B6RV676','6349354','BWQ7SK4','BVB7YT3','BMGQCT8','B5TQ1L1','BGK4T39','BNNMVP5','BNVTTV0','BRK2Z98','6490928','6282062','6406271','B0TB3F9','B08X163','0753810','BNTBRX6'],    from_symbol_type=symbol_conversion.SymbolTypes.SEDOL,    to_symbol_types=[        symbol_conversion.SymbolTypes.RIC    ],).get_data()

It did return me some values and not all, I am expecting if there is no data at the backend, it should give me NA or something rather than skipping the sedol altogether, Can u please guide on this

So, my question is whether you have a better strategy to compute for a set of banks their historical YTM of outstanding unsecured debt and whether you could possibly provide a useful python code that I can build up on. Or is the only way forward the way I described above?

We are using https://api.refinitiv.com/data/filings/v1/retrieval/search/{identifier}/{value} API to get the signed URL to fetch actual file. We want to apply a integrity check to ensure that file is not tampered in transit. Can you please check and confirm what is the correct way to apply the same.

When I am running the R code using Refinitv API, it always gave me the error 2026-06-02 13:32:51,973 P[14388] [MainThread 21524] UDF Core request failed. Gateway Time-out
2026-06-02 13:32:51,973 P[14388] [MainThread 21524] HTTP request failed: EikonError-

Hope to hear from your team soon. Thanks in advance.

'<BBJPY3M=>-.5*(OIJPY3M(IB) +OIJPY3M(IO))'

how would I get that same data using the lseg.data python library and it's get_history function:

df_history = ld.get_history(
universe=["GB10YT=RR"],
fields=["BID", "HIGH_1", "LOW_1", "OPEN_PRC"],
interval="1D",
start="2026-01-01",
end="2026-05-01"
)

import lseg.data as ld
from lseg.data.discovery import Chain
ld.open_session()

chain = Chain(name="0#GOOGL*.U")print(chain.constituents)

df = ld.get_history(
universe = chain.constituents[1:],
fields = ['TRDPRC_1','ACVOL_UNS'],
start = '2026-01-01',
end = '2026-06-02',
interval = '1d')
df = df.fillna(0)
df

Somehow, the code only reads the first part / pulls the constituents but not the volume and price data:

Here's the Excel formula:

=@RDP.HistoricalPricing($B$5:$B$1000,"TRDPRC_1;ACVOL_UNS","START:"&$B$2&" END:"&$B$3&" INTERVAL:P1D SOURCE:RFV",,"TSREPEAT:NO NULL:ZERO CH:IN;Fd RH:Timestamp",D4)

We'll appreciate it if you could check and advise.

Thank you very much!

Best Regards,

Yoy

One of user is asking, The Discovery Symbology API (image below) is designed precisely to map between different identifiers (RIC, ISIN, CUSIP, PermID, etc.) and supports an internal identifier called DatastreamId among the “LSEG specific and heritage identifiers.”

So this works for Equities / ETF and similar.

Please confirm whether there is any API connection among those in the LSEG catalogue that allows us to do the same thing with Datastream macroeconomic time series (image2)?

1. How can we identify which MT568 messages are linked to a specific MT564? For example, if there are two MT564 messages with the same CORP reference ID, each having its own MT568 messages, how do we map each MT568 to the correct MT564?
2. We were previously informed that only the latest SWIFT messages will be returned via the API. If that is the case, how can multiple MT564 messages be received? Could you also share an example (sample SWIFT message or RIC/ISIN) where multiple MT564 messages exist?

API URL -
https://selectapi.datascope.lseg.com/RestApi/v1/Extractions/ExtractRaw

API Body -
{
"ExtractionRequest": {
"@odata.type": "#DataScope.Select.Api.Extractions.ExtractionRequests.CorporateActionsIsoExtractionRequest",
"Condition": {
       "ReportDateRangeType": "Delta",
       "PendingEventsPreviousDays": 1,
"ReportIsoEvents": [
"BIDS",
"TEND",
"EXRI",
"PRIO",
"CONV",
"EXOF",
"MRGR"
],
"IncludeNonPendingEvents": true,
"GrossAmountOnlyForPaymentEvents": true,
"ExcludeNilPaidFromPaymentEvents": true,
"IncludeCusipCinsIn35B": true,
"Wrap35BLines": true
},
"IdentifierList": {
"@odata.type": "#DataScope.Select.Api.Extractions.ExtractionRequests.InstrumentIdentifierList",
"InstrumentIdentifiers": [
{
"Identifier": "EDPR.LS",
"IdentifierType": "Ric",
"Source": "*"
}
],
"ValidationOptions": {
"AllowOpenAccessInstruments": true,
"AllowHistoricalInstruments": true,
"AllowInactiveInstruments": false
},
"UseUserPreferencesForValidationOptions": false
}
}
}

Calls were batched as 20 partners × 31 financial fields × 16 quarters per
request. Most errors came back as:

Error code -1 | Unable to collect data for the field 'TR.F.TotRevenue'
and some specific identifier(s).
Requested universes: ['4296309931', '4296353850', ...20 IDs...]
Requested fields: ['TR.F.TOTREVENUE(PERIOD=FQ12016,FRQ=FQ,SCALE=6,CURN=USD)', ...]

We were not able to determine from the error which of the 20 identifiers
in the batch caused the failure, nor which of the 31 fields. Examples of
affected partners:

| Identifier | Company name |
|---|---|
| 4296309931 | Huawei Technologies Co Ltd |
| 4296353850 | Booz Allen Hamilton Inc |
| 5000144489 | Unison Industries LLC |

Our questions:

1. Can the helpdesk identify, for each batch in the attached
   error_partners.csv, which specific identifier(s) caused the
   "Unable to collect data" error?
2. Is there a Refinitiv API setting / call pattern that would return
   per-identifier errors rather than collapsing the batch?
3. For the affected partners individually, do you have data available
   under a different identifier or field naming convention?
4. Several batches reference periods as early as FQ12000. Could the
   error be that Refinitiv has no historical data going back that far
   for these specific partners? If so, what is the earliest available
   period per identifier

• Phase 2: value-chain partner discovery via
  get_data(universe=[...focal RIC...], fields='TR.SCRelationship*')
  for 1,662 focal US-listed companies.
  → returned 13,265 unique supply-chain partners
• Phase 3: quarterly financial pull for those partners via
  get_data(universe=[...partner identifier...], fields='TR.F.*')
  for the period 2000-Q1 to 2025-Q3 (61 quarterly financial fields).

Out of the 11,278 partners we attempted to pull financials for, the
outcomes were:

| outcome | count | meaning |
|---|---:|---|
| done — full quarterly financials returned | 5,269 (46.7%) | Usable, no help needed |
| no_data — RIC valid but Refinitiv returned blank | 931 (8.3%) | Need confirmation these truly have no data |
| deferred — OrgID only, no tradeable RIC available | 3,638 (32.3%) | Need RIC or alternative identifier |
| error — API returned an error during batched pull | 1,440 (12.8%) | Need root cause + retry guidance |

We would like the helpdesk's assistance recovering data for the 6,009 partners
in the bottom three buckets. Detail and asks below.

Bucket 1 — deferred (3,638 partners) — Need RICs or alternative identifiers

These companies were returned by Refinitiv's value-chain API as supply-chain
partners, but with only a numeric organisation ID (e.g. 5034750648) and
no tradeable Reuters Instrument Code (RIC). Our get_data calls against the
financial fields require a RIC.

Examples:

| OrgID | Company name |
|---|---|
| 5034750648 | Madrilena Red de Gas SAU |
| 5040225699 | Veeam Software Group GmbH |
| 4298209955 | Black & Veatch Holding Co |

Our questions:

1. For each OrgID in the attached list deferred_partners.csv, can you
   provide the corresponding RIC (or any other identifier such as ISIN,
   SEDOL, or Refinitiv permID) that would allow TR.F.* financial pulls?
2. If a partner is genuinely a private company with no listed instrument
   and no available financials, can you confirm that explicitly so we can
   exclude them with certainty?
3. Is there a documented Refinitiv API method to convert OrgIDs to RICs
   programmatically that we should be using? (We tried
   symbology conversion via lseg.data.discovery.search but with mixed
   results.)

Bucket 2 — error (1,440 partners) — Need root cause for API errors

Calls were batched as 20 partners × 31 financial fields × 16 quarters per
request. Most errors came back as:

Error code -1 | Unable to collect data for the field 'TR.F.TotRevenue'
and some specific identifier(s).
Requested universes: ['4296309931', '4296353850', ...20 IDs...]
Requested fields: ['TR.F.TOTREVENUE(PERIOD=FQ12016,FRQ=FQ,SCALE=6,CURN=USD)', ...]

We were not able to determine from the error which of the 20 identifiers
in the batch caused the failure, nor which of the 31 fields. Examples of
affected partners:

| Identifier | Company name |
|---|---|
| 4296309931 | Huawei Technologies Co Ltd |
| 4296353850 | Booz Allen Hamilton Inc |
| 5000144489 | Unison Industries LLC |

Our questions:

1. Can the helpdesk identify, for each batch in the attached
   error_partners.csv, which specific identifier(s) caused the
   "Unable to collect data" error?
2. Is there a Refinitiv API setting / call pattern that would return
   per-identifier errors rather than collapsing the batch?
3. For the affected partners individually, do you have data available
   under a different identifier or field naming convention?
4. Several batches reference periods as early as FQ12000. Could the
   error be that Refinitiv has no historical data going back that far
   for these specific partners? If so, what is the earliest available
   period per identifier

What we will do with the recovered data

Any RICs / identifiers you can provide for the deferred and error buckets
will be re-pulled through the same batched TR.F.* pipeline. This is for
internal credit-rating research only; no client-facing redistribution. We
estimate this will recover financial data for roughly 30-50% of the 6,009
missing partners, which would meaningfully improve the supply-chain
coverage of our rating prediction model.

If the helpdesk needs a sample of our successful pull pattern (the 5,269
done partners) to better diagnose what is different about the missing
ones, we are happy to share a sample script and field list.

Attached files

1. deferred_partners.csv — 3,638 rows: lookup_id, company_name, identifier
2. error_partners.csv — 1,440 rows: lookup_id, company_name, identifier, error_message_first_50_chars
3. no_data_partners.csv — 931 rows: lookup_id, company_name, ric, identifier

Total: 6,009 partners requiring helpdesk attention.

Thanks very much in advance — happy to jump on a call if anything in this
note needs clarifying.

Thank you in advance

I'm trying to use LSEG Data API for Python to pull historical options data for ICE Brent Crude (e.g. the chain: 0#LCO+). I know how to construct expired option RICs e.g. LCO7000A5^A25, LCO7000A4^A24. I generate an extensive list of potential RICs that have expired, with strikes from say 0, 1, 2, ...., 299, 300. Within this list, a prior, there will be options that never traded and don't have a price.
If I use the function call get_data(["LCO7000A5^A25", "LCO7000A4^A24"], fields="TR.SETTLEMENTPRICE") this returns empty.
If I use the function get_history(["LCO7000A5^A25", "LCO7000A4^A24"], fields="SETTLE") this returns settle prices.
However, get_history will fail completely if the universe I supply contains RICs which are invalid (which I don't know prior and what I'm trying to determine).
get_data() is designed to handle invalid RICs, such that it still returns data for valid RICs and NANs for invalid RICs.
How do I determine historically valid RICs?

I am currently finalizing the architecture for a 10-year quantitative equity options backtest using the Refinitiv Data API (refinitiv.data in Python). To complete our data pipeline, we need to extract a specific set of point-in-time historical options analytics for a custom universe of US equities.

Specifically, we are looking to retrieve the following daily historical data points for the underlying equity RICs over the last 10 years:

1. Options Average Daily Volume (ADV): e.g., 10-day or 30-day trailing options contract volume for the underlying.
2. 25-Delta Risk Reversals (RR25): The implied volatility skew between the 25-delta calls and 25-delta puts.
3. Volatility Risk Premium (VRP): The spread between Implied Volatility (e.g., 30-day ATM IV) and Realized Volatility.
4. Put/Call Ratio (PCR): Daily volume and/or open interest Put/Call ratio for the underlying options.

Our Technical Constraint: For computational efficiency and to respect API limits, we absolutely must pull these as pre-calculated, top-level metrics mapped directly to the underlying equity RIC. We cannot build a pipeline that requires us to historically query the entire option chain (strike by strike, expiry by expiry) across 1,000+ stocks every single day for 10 years just to calculate a 25-delta risk reversal or a put/call ratio.

My Questions:

• Are there direct TR.* fields available for these specific options metrics that we can pass into rd.get_history()?
• If not, does the Instrument Pricing Analytics (IPA) service have a lightweight method to output these specific Greeks and volume metrics historically without querying the full chain?
• Are there any specific Data Item Browser formulas or backend data models we should be subscribing to in order to access this point-in-time data cleanly?

Thank you so much in advance for your time and guidance!

response = ld.get_data(universe = '0#MAL+', fields = 'DSPLY_NAME', parameters = {'SDate':'2005-01-01'})

The SDate paramaters does not impact the result of the function. What is the easiest way to retrieve the constituents for a given date?

Thanks

The questions:
1. The ETA coding guideline if any (e.g., in EMA, should no logging in the onXXXMsg)
2. Only one machine id, is that possible to make the message consumption to be multi-threaded? so as to accelerate the message ingestion.