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)?

Symbol Conversion returned data only for 6 out of the 12 bond CUSIP requested and among the 6 two of them don't have ISIN

For the same CUSIP when using Fundamental And Reference module response has 12 records, but data for only 6 of them with all the 6 having ISIN.

Below is a similar example based on equity CUSIPs. (For equity it seems like Symbol Conversion returns data only if TR.CUSIP is available (Canada/US))

Please help with the below queries

1. Why no data is returned for some of the securities and why does Symbol Conversion module return lesser data fields (missing ISINs) compared to Fundamental And Reference module?

2. Which one of these modules/methods is preferred in terms of performance and correctness?

3. What instrument types are supported by the param "universe" in "get_data()" method, it seems to work with ISIN, CUSIP and RIC values? Can we provide instrument type to this method to improve performance/correctness and avoid service from determining the instrument types?

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

• LSEG Data Library for Python (lseg.data / formerly refinitiv.data)
• Portfolio Analytics (PAL) via the portfolio-analytics and o-management endpoints
• Python 3.11, running in CodeBook

What I'm building

I reconstruct a portfolio's closed positions (fully sold or redeemed in the past) from PAL transaction history, so I can produce a per-trade realized-P&L report. For each closed position I need the instrument identity (ISIN, issuer, coupon, maturity) to compute and label the trade.

How identification normally works (and works fine for ~85% of positions)

For active and most closed positions, I get the instrument identity from PAL holdings statements - each holdings snapshot lists the instrument with its issueName/ISIN. I match a transaction to a position via a shared internal id, and the position already carries its ISIN from the holdings snapshot. This works well.

The problem (the remaining ~15%)

Some positions were opened and fully closed between two holdings-snapshot dates. PAL apparently never took a holdings snapshot while these instruments were held, so they never appear in any holdings statement on any date. For these, the transaction record is the only trace - and the transaction's instrument reference contains only an internal TOPAS identifier, with no ISIN/CUSIP/RIC and an empty name.

Concretely, the transaction's symbol/security item looks like:

<iframe>

{"securityItem": {"symbolValues": [{ "type": "TOPASId", "value": "150462714" }]}}

That's the entire instrument reference - type: "TOPASId" and a numeric value, nothing else.

What I've already tried (and ruled out)

<iframe />

1. Holdings densification - I scanned the full set of available holdings dates, then added targeted extra dates around each transaction window (100+ extra dates). The instrument's TOPASId is simply absent from holdingsDetails on every probed date. PAL does not appear to retain it anywhere in holdings.
2. Ticker / name heuristics - not viable; these transactions carry no name, ticker, ISIN, or CUSIP at all.
3. Manual mapping - works but is not scalable and defeats the purpose of automation.

The question

Is there a supported way to resolve a PAL TOPASId to a standard instrument identifier (ISIN / RIC / PermID), outside the PAL holdings endpoint?

Specifically:

• Does lseg.data symbology / symbol_conversion accept a TOPASId as an input identifier type? If so, what is the correct from_symbol_type (or equivalent) value?
• Is TOPASId queryable via the Search / discovery API (e.g. as an indexed field), so I could look the instrument up by that id?
• Is there any other endpoint that maps PAL's internal TOPAS identifier to a public identifier - given that the instrument does exist in LSEG's universe (it's an LSEG-internal id), it's only the PAL portfolio endpoint that doesn't surface its public identifiers for these closed-out trades?

Minimal anonymized example of what I'd like to achieve

import lseg.data as ldld.open_session()

This is the only identifier I have for a closed-out position:

topas_id = "150462714" # PAL transaction securityItem -> symbolValues -> type "TOPASId"

DESIRED: resolve TOPASId -> ISIN / RIC, without needing a PAL holdings snapshot.

Attempt A - symbol conversion (does TOPASId work as a from-type here?):

res = ld.symbol_conversion.Definition(symbols=[topas_id],from_symbol_type="???", # <-- is there a value that means "TOPASId"?to_symbol_types=["ISIN", "RIC"],).get_data()print(res.data.df)

Attempt B - search by the id as a query / property:

res2 = ld.discovery.search(query=topas_id,# or filter=f"TOPASId eq '{topas_id}'" <-- is TOPASId a searchable field?)print(res2)

ld.close_session()

I'm looking for either:

• the correct symbol-type / field to make one of the above work, or
• confirmation that PAL does not retain identification for positions closed entirely between holdings snapshots, so that a manual mapping is the only option.

Any pointers from people who've dealt with TOPAS internal ids or PAL transaction-level enrichment would be much appreciated.

Thank you.

i'm wondering why new methods exposed under Lseg library (content 'symbol_convesrtion' and discovery side 'convert_symbols') there is no best_match option as were proposed by eikon function (get_symbology).

the ricStatusMap returns "NOT_EXIST" for these Korean Equity Future Spread RICs

Date: March 2026
Products affected: Eikon Data API — EikonGetSymbology endpoint
Secondary issue: Case inconsistency in delisted RIC codes returned by EikonGetSymbology

Setup
import lseg.data as ld
import pandas as pd
​
pd.set_option('display.max_columns', None)
pd.set_option('display.width', None)
pd.set_option('display.max_colwidth', 80)
pd.set_option('display.max_rows', 100)
​
ld.open_session()
​
Summary
EikonGetSymbology (exposed in the LSEG Data Library as ld.convert.symbol() with symbol_type mapping) does not reliably resolve bare-ticker RICs (e.g., HES, A) to their exchange-suffixed equivalents (e.g., HES.N, A.N). ld.get_data() resolves both forms to the same company, but ld.convert.symbol() treats them as different instrument universes. This makes it impossible to programmatically track RIC lifecycle events (delistings, ticker changes, corporate actions) for any instrument stored under its bare ticker.

A separate issue: ld.convert.symbol() returns delisted RIC codes with inconsistent casing relative to the input (e.g., 1COV.DE returns 1COv.DE^L25).

Issue 1: Bare-Ticker Symbology Resolution
The Inconsistency
ld.get_data() treats bare tickers and exchange-suffixed RICs as equivalent. Both return identical company data. However, ld.convert.symbol() does not recognise this equivalence.

Step 1: Confirm both forms resolve to the same company in ld.get_data()

​
step1_df = ld.get_data(
universe=['HES', 'HES.N'],
fields=['TR.InstrumentIsActive', 'TR.CommonName', 'TR.ExchangeName']
)
print('Both HES and HES.N resolve to Hess Corp:')
step1_df
​
Both forms return identical company data: Hess Corp, InstrumentIsActive = False, listed on NYSE.
The Eikon data model treats HES and HES.N as the same instrument.

Step 2: Query symbology with the exchange-suffixed form (works)

​
step2_df = ld.convert.symbol(
symbols=['HES.N'],
from_symbol_type='RIC',
to_symbol_types=['RIC'],
best_match=False
)
print('Exchange-suffixed form correctly returns delisted code:')
step2_df
​
The exchange-suffixed form HES.N correctly resolves to the delisted successor HES.N^G25.
This is the expected and correct behaviour.

Step 3: Query symbology with the bare ticker (fails)

​
step3_df = ld.convert.symbol(
symbols=['HES'],
from_symbol_type='RIC',
to_symbol_types=['RIC'],
best_match=False
)
print(f'Bare ticker returns {len(step3_df)} results:')
print(f'Does HES.N appear? {any("HES.N" in str(v) for v in step3_df.values.flatten() if v is not None)}')
step3_df
​
The bare ticker HES returns ~96 unrelated instruments -- derivatives, warrants, HK options, and cross-listed products -- with zero NYSE equity results and zero delisted equity results.
There is no path from HES to HES.N or HES.N^G25 through the symbology service.

The Inconsistency Also Exists for Active Tickers
This is not limited to delisted stocks. Active bare tickers produce inconsistent results.

​
active_tests = [
('A', 'A.N', 'Agilent Technologies'),
('GE', 'GE.N', 'GE Aerospace'),
('BA', 'BA.N', 'Boeing'),
('AAPL', 'AAPL.O', 'Apple'),
]
​
results = []
for bare, suffixed, name in active_tests:
df = ld.convert.symbol(
symbols=[bare],
from_symbol_type='RIC',
to_symbol_types=['RIC'],
best_match=False
)
n_results = len(df)
# Check if the suffixed form appears anywhere in the results
flat = [str(v) for v in df.values.flatten() if v is not None]
found = any(suffixed in v for v in flat)
results.append({
'Bare Ticker': bare,
'Expected Suffixed': suffixed,
'Company': name,
'Results Returned': n_results,
'Suffixed Form Found?': found
})
​
active_test_df = pd.DataFrame(results)
print('Active bare ticker resolution test:')
active_test_df
​
Bare ticker Company ld.convert.symbol() results Includes suffixed form?
A Agilent Technologies (NYSE) ~64 results No -- A.N not returned
GE GE Aerospace (NYSE) ~97 results Yes -- GE.N at position 5
BA Boeing (NYSE) ~97 results Yes
AAPL Apple (NASDAQ) ~99 results Yes -- AAPL.O returned
For A, there is no programmatic way to discover that A.N is the exchange-suffixed equivalent using ld.convert.symbol() alone.
For GE, the .N form is present but buried among ~97 alternatives with no ranking or filtering to distinguish the primary equity from derivatives and cross-listings.

Why This Matters
LSEG's own data model encourages storing bare tickers. TR.PrimaryRIC for A.N returns A:

​
primary_df = ld.get_data(
universe=['A.N'],
fields=['TR.PrimaryRIC']
)
print('TR.PrimaryRIC for A.N:')
primary_df
​
LSEG designates the bare ticker as the TR.PrimaryRIC value. A system that follows LSEG's data model and stores TR.PrimaryRIC will accumulate bare tickers.

When those stocks eventually delist, the system cannot use ld.convert.symbol() to find the successor code -- the bare ticker resolves to a different instrument universe than the exchange-suffixed form.

Confirmed Delisted Cases
The table below confirms that the exchange-suffixed form correctly resolves while the bare form does not.

​
delisted_cases = [
('HES', 'HES.N', 'Hess Corp', 'Chevron acquisition'),
('SNV', 'SNV.N', 'Synovus Financial', 'Columbia Banking acquisition'),
]
​
for bare, suffixed, name, event in delisted_cases:
print(f'\n=== {name} ({event}) ===')
# Suffixed form
df_suf = ld.convert.symbol(
symbols=[suffixed],
from_symbol_type='RIC',
to_symbol_types=['RIC'],
best_match=False
)
print(f' {suffixed} -> {len(df_suf)} result(s):')
print(f' {df_suf.to_string()}')
​
# Bare form
df_bare = ld.convert.symbol(
symbols=[bare],
from_symbol_type='RIC',
to_symbol_types=['RIC'],
best_match=False
)
flat = [str(v) for v in df_bare.values.flatten() if v is not None]
has_equity = any(suffixed in v for v in flat)
print(f' {bare} -> {len(df_bare)} results, contains {suffixed}? {has_equity}')
​
Bare Ticker Company Event ld.convert.symbol(bare) ld.convert.symbol(suffixed)
HES Hess Corp Chevron acquisition ~96 results, 0 equities HES.N -> HES.N^G25
SNV Synovus Financial Columbia Banking acquisition ~60+ results, 0 equities SNV.N -> SNV.N^A26
In both cases, the correct delisted code exists and is returned when queried with the exchange-suffixed RIC. The symbology service simply cannot bridge from the bare form to the suffixed form.

Issue 2: Case Inconsistency in Delisted RIC Codes
The Problem
ld.convert.symbol() returns delisted RIC codes with altered casing relative to the original.

​
case_df = ld.convert.symbol(
symbols=['1COV.DE'],
from_symbol_type='RIC',
to_symbol_types=['RIC'],
best_match=False
)
print('Symbology result for 1COV.DE:')
case_df
​

​
original_ric = '1COV.DE'

returned_values = [str(v) for v in case_df.values.flatten() if v is not None and '^' in str(v)]
​
if returned_values:
delisted_ric = returned_values[0]
base_of_delisted = delisted_ric.split('^')[0]
print(f'Original RIC: {original_ric}')
print(f'Delisted RIC: {delisted_ric}')
print(f'Base of delisted: {base_of_delisted}')
print(f'Exact match? {original_ric == base_of_delisted}')
print(f'Case-insensitive? {original_ric.upper() == base_of_delisted.upper()}')
# Show the exact character difference
for i, (a, b) in enumerate(zip(original_ric, base_of_delisted)):
if a != b:
print(f' Character {i}: input={repr(a)} vs returned={repr(b)}')
else:
print('No delisted RIC found in results -- inspect case_df above.')
​
The original RIC 1COV.DE (Covestro, Xetra) is returned in the RIC column with correct casing, but the delisted successor in the RICs column has 1COv.DE^L25 -- a lowercase v that was not present in the original.

Why This Matters
RIC codes are treated as exact identifiers in financial systems. Standard string matching (old_ric + "^" prefix check) fails because the casing changed. This forces every consumer of ld.convert.symbol() to implement case-insensitive matching for delisted RIC detection -- a workaround for what should be case-stable data.

Additional Evidence: No Existing Field Bridges Bare to Suffixed
There is currently no Refinitiv field that reliably returns the exchange-suffixed form when given a bare ticker.

​
bridge_df = ld.get_data(
universe=['A', 'A.N', 'HES', 'HES.N'],
fields=['TR.RICCode', 'TR.PrimaryRIC', 'TR.CommonName']
)
print('TR.RICCode echoes back the input; TR.PrimaryRIC returns the bare form:')
bridge_df
​
Input TR.RICCode TR.PrimaryRIC Provides .N form?
A A A No
A.N A.N A Only if you already know it
HES HES HES No
HES.N HES.N HES Only if you already know it
TR.RICCode simply echoes back the input form.
TR.PrimaryRIC always returns the bare form, even when queried with the suffixed version.
Neither provides a reliable path from bare ticker to exchange-suffixed RIC.
What We Are Asking For
Request 1
ld.convert.symbol() / EikonGetSymbology should include the exchange-suffixed equity RIC (e.g., HES.N) among the returned alternatives when queried with a bare ticker (HES) -- at minimum for US equities, where the bare form is designated as TR.PrimaryRIC.

Request 2
Expose a field (e.g., TR.ExchangeRIC) in ld.get_data() that returns the exchange-suffixed form for any valid input RIC. Currently, TR.RICCode echoes back the input form, and TR.PrimaryRIC returns the bare form even when queried with the suffixed version. Neither provides a reliable path from bare ticker to exchange-suffixed RIC.

Request 3
Delisted RIC codes should preserve the casing of the original RIC. If the active RIC is 1COV.DE, the delisted form should be 1COV.DE^L25, not 1COv.DE^L25.

Summary

1 Bare-ticker RICs not resolved to exchange-suffixed equivalents Critical ld.convert.symbol() Unresolved
2 Delisted RIC codes returned with altered casing Medium ld.convert.symbol() Unresolved
Impact
Issue 1 blocks programmatic tracking of RIC lifecycle events for instruments stored under their LSEG-designated TR.PrimaryRIC (bare ticker). This affects every system that follows LSEG's own data model.
Issue 2 forces consumers to implement case-insensitive matching as a workaround for what should be case-stable identifier data.

three questions :

• is it possible to access /data/news/v1/metadata/{QCODE} API with python lseg-data library ?
• is it possible to cache authentication token (in a file ?) in order to avoid extra authentications
• is symbology available in lseg-data ? I can not find it

regards

"We've recently added ~500 new cusips into our universe which we use to fetch market data. It now seems like the /discovery/symbology/v1/lookup call to map cusips to RIC's is now timing out at around 100-200 cusips. Is there a limit on how many cusips we can query for, and if so what is that limit?"

Tried, using symbology and symbol_conversion functions/classes but they only return one RIC. The search function can fetch multiple RICs but this is incomplete.

Is there an approach that uses lseg library instead of Eikon? I noticed that the module will be unsupported in the upcoming patches so if possible I want the solution using lseg module.

But my main question is: is there a function where I can put an ISIN code and get the primary quote RIC?

Resolution provided

When you enter an ISIN in codebook, you will have to select a RIC to use. To get the Primary RIC quote you can use the code below.

import refinitiv.data as rdrd.open_session()df = rd.get_data(universe = ['FER.MC'],fields = ['TR.PrimaryQuote'])display(df)

Client follow up

I am a bit surprized here. In the Python code you had provided to us, the ISIN code is the sole we use. Normally, it is sufficient to get the data. But not for ferrovial.... In what you provided in your answer, you used the FER.MC RIC... But this, I do not have for all the ISIN I provide to the system. To give you some insight, here is the part of the code we use:

#Calcul des champs maison

resultat.fillna(0, inplace=True)resultat["Value"]=((resultat["Relative Valuation Region Rank"]+resultat["Price / Intrinsic Value Region Rank"])/2)/10resultat["Quality"]=(resultat["Earnings Quality Region Rank, Current"])/10resultat["Momentum"]=((resultat["Analyst Revisions Model Region Rank"]+resultat["Price Momentum Region Rank"])/2)/10resultat["Smart_Holdings"]=(resultat["SmartHoldings Region Rank"])/10resultat["Note Starmine"]=(resultat["Value"]+resultat["Quality"]+resultat["Momentum"]+resultat["Smart_Holdings"])/4resultat.rename(columns={"Instrument": "ISIN"},inplace=True)cols=['ISIN','Note Starmine','Value','Quality','Momentum','Smart_Holdings','Value-Momentum Region Rank','Price Momentum Region Rank','Analyst Revisions Model Region Rank','Price / Intrinsic Value Region Rank','Relative Valuation Region Rank','SmartHoldings Region Rank','Short Interest Country Rank','Insider Country Rank','Earnings Quality Region Rank, Current','Credit Combined Region Rank','Credit SmartRatios Region Rank','Credit Structural Region Rank','Credit Text Mining Region Rank']resultat=resultat[cols]resultat_clean=pd.concat([pd.DataFrame([resultat.columns], columns=resultat.columns), resultat], ignore_index=True)output=pd.merge(output_nom,resultat_clean.drop_duplicates(subset='ISIN'),on='ISIN', how='inner')

#Export

date_txt=datetime.datetime.today().strftime('%Y%m%d')output.to_excel("F:/_applicationdata/EUDA_Investissements_Dataset_FR/44_Starmine/Historique/Starmine_"+date_txt+".xlsx",index=False,sheet_name="Feuil1")

Hello,

I know that there have been previous questions on the topic, but the answers did not solve the issue for me. I have a vector of company names from the USPTO.

company_names = df["disambig_assignee_organization"].dropna().tolist()

print(company_names[:10])

Examples of firm names:

'International Business Machines Corporation', 'CANON KABUSHIKI KAISHA', 'Fujitsu Limited',

I tried to use OpenPermID, but it does not return anything.

from OpenPermID import OpenPermID

opid = OpenPermID()

opid.set_access_token("TOKEN") ## My actual token



output,err = opid.match(company_names)

output

print(output)  ## Here i just get "None" 



 response = symbol_conversion.Definition(

    symbols=output["Match OpenPermID"].str.split('-').str[1].tolist(),

    from_symbol_type=symbol_conversion.SymbolTypes.OA_PERM_ID,

    to_symbol_types=[

        symbol_conversion.SymbolTypes.RIC

    ]

).get_data()


response.data.df

Since i get "None" in "Output", the response gives me an error message.

Is there a chance we could retrieve the RICs ?

I’m using the LSEG Data Library for Python to retrieve instrument identifiers (ISIN, CUSIP, SEDOL, etc.) from RICs as part of a global equity mapping pipeline. For most instruments, this works well. However, for a subset of equities the API does not return all identifiers, even though they are clearly visible in Refinitiv Workspace.

import lseg.data as ld

ld.open_session()

ld.get_data('VSSL.BO',['TR.RIC', 'TR.ISIN', 'TR.CUSIP', 'TR.SEDOL', 'TR.InstrumentType'])

Issue:
The output does not include TR.CUSIP for this RIC.
But when I check the same instrument in Refinitiv Workspace, the CUSIP is available under the instrument’s identifiers.

This behavior is not limited to one RIC — I am working with a large universe of global equities, and the identifier completeness is crucial for my downstream mapping and reconciliation workflows.

1. Why would ld.get_data() omit certain identifiers (e.g., CUSIP) even though they appear in Workspace for the same RIC?
2. Is there an alternative or recommended method to reliably retrieve all identifiers for global equities via the Python API?

What works / what doesn’t

• In Workspace (desktop), if I search by SEDOL I can see the security and its RIC.
• In Python, calling get_symbology returns RIC = NaN for many of the same SEDOLs. Because I have 1,000+ symbols, manual lookup isn’t feasible.

Sample Code I am Using:

import pandas as pd
import eikon as ek # Workspace/Eikon Python

for k, sedol in enumerate(df1['fld_sedol']):
tempDF = ek.get_symbology(sedol, from_symbol_type='SEDOL', to_symbol_type='RIC')
if 'RIC' in tempDF.columns and not pd.isna(tempDF['RIC'][0]):
tempRIC = tempDF['RIC'][0]
idenDF = ek.get_symbology(tempRIC) # expand to CUSIP/ISIN
if {'CUSIP','ISIN','RIC'}.issubset(idenDF.columns):
df1.loc[k,'fld_cusip'] = idenDF['CUSIP'][0]
df1.loc[k,'fld_isin'] = idenDF['ISIN'][0]
df1.loc[k,'fld_ric'] = idenDF['RIC'][0]
else:
print(f"SEDOL {sedol} → RIC = NaN")

Highlighted is sample record for which, we unable to get RIC via API.

But the same sedol has RIC in workstation:

My component at startup will fetch a list of sedol identifiers.

The component will need to subscribe to RTO using EMA library (Real-Time Feeds) to receive the price data using the sedols list.

Obviously subscription needs to be done using RICs but not sedols.

So the mapping between sedols and RICs needs to be done automatically at application startup.

I've already tried Bulk Real-Time RICs Search APIs.

https://developers.lseg.com/en/article-catalog/article/bulk-real-time-rics-search-apis

real-rime-bulk-search-api-user_guide.pdf

It does not look like this search API is something I can use in my use-case?

So my question is there some tool/endpoint I could use to create such mapping on the fly?

Thanks

Grzegorz

Few weeks ago I asked a question on how to get RICs for a given set of ISINs programmatically.

This was my question:-

API to get RICs for a given ISIN (Euro/UK Fixed Income Bonds) - LSEG Developer Community

So based on the answer I am using the dotnet samples given here

LSEG-API-Samples/Example.DataLibrary.DotNet: Example projects demonstrating access to the Refinitiv Data Platform using the Refinitiv Data Library for .NET.

Our firm has "Deployed Streaming" trep infra in our datacenter. So im trying to use that.

I am running the dotnet samples and using this specific code sample from the solution - "2.5.01-Symbology-Convert.cs". And trying to connect to our internal "Deployed Streaming".

It gets connected initially, the session is opened, but then when I make actual call of RIC conversion

SymbolConversion.Definition().Symbols("US5949181045", "US02079K1079")
.FromSymbolType(SymbolConversion.SymbolType.ISIN)
.ToSymbolType(SymbolConversion.SymbolType.RIC)
.GetData();

this call fails.

Below are the logs from the app:-

10/27/2025 12:55:33 PM: State: Pending. PlatformSession (Deployed) is Pending
10/27/2025 12:55:33 PM: Event: StreamConnected. {
"Contents": "Successfully connected into the WebSocket server: ads2.trep-s.ppe-ch4.fcstone.com:15000"
}
10/27/2025 12:55:34 PM: Event: StreamAuthenticationSuccess. {
"Contents": "Successfully logged into streaming server ads2.trep-s.ppe-ch4.fcstone.com:15000"
}
10/27/2025 12:55:35 PM: State: Opened. PlatformSession (Deployed) is Opened
10/27/2025 12:55:35 PM: Event: StreamDisconnected. {
"Contents": "Connection to the WebSocket server [ads2.trep-s.ppe-ch4.fcstone.com:15000] down. Microsoft's ClientWebSocket Connection closed [Going Away (EndpointUnavailable)]"
}
10/27/2025 12:55:36 PM: State: Closed. PlatformSession (Deployed) is Closed

Failed to execute.
Exception: NotSupportedException Failed to execute GetDataAsync request. The session does not support data requests [/discovery/searchlight/v1/lookup]

https://{{RDP_HOST}}/discovery/symbology/v1/lookup

I can do

{  "from": [    {      "identifierTypes": [        "ISIN"      ],      "values": [        "ISIN1",        "ISIN2",        "ISIN3",        "ISIN4",        "ISIN5",        "ISIN6"      ]    }  ],  "type": "Predefined",  "route": "FindPrimaryRIC"}

Question: What is the maximum numbers of isins that I can put in the array in the from field?

Thanks!

The output that I want is USA country code specific but it is showing Exchanges from Thailand and Vienna.

Also my asset class are code for funds, equities, certificates and bonds but Commodities futures also show in my output.

Here is the code:

from lseg.data.content import symbol_conversion

import lseg.data as ld

import pandas as pd

my_tickers = ['AIG PR A', 'PTT', 'BRKa', 'ANPA', 'BADDDDYYYYYDDY', 'DNB', 'VRA', 'LAWR', 'STR', 'TYO']

ld.open_session()
response = symbol_conversion.Definition(

symbols=my_tickers,

from_symbol_type=symbol_conversion.SymbolTypes.TICKER_SYMBOL,


to_symbol_types=[

    symbol_conversion.SymbolTypes.RIC


],

# preferred_country_code = "G:6J", # USA USA = "G:6J"


preferred_country_code = symbol_conversion.CountryCode.USA,


asset_class=[


    symbol_conversion.AssetClass.FUNDS,


    symbol_conversion.AssetClass.EQUITIES,


    symbol_conversion.AssetClass.CERTIFICATES,


    symbol_conversion.AssetClass.BONDS,


    ],


asset_state=symbol_conversion.AssetState.ACTIVE,

).get_data()

ld.close_session()

response = pd.DataFrame(response.data.df).reset_index().rename(columns={'index': 'Ticker'})

print(response)

from lseg.data.content import symbol_conversion

import lseg.data as ld

import pandas as pd

my_tickers = ['AIG PR A', 'PTT', 'BRKa', 'ANPA', 'BADDDDYYYYYDDY', 'DNB', 'VRA', 'LAWR', 'STR', 'TYO']

ld.open_session()
response = symbol_conversion.Definition(

symbols=my_tickers,

from_symbol_type=symbol_conversion.SymbolTypes.TICKER_SYMBOL,


to_symbol_types=[

    symbol_conversion.SymbolTypes.RIC


],

# preferred_country_code = "G:6J", # USA USA = "G:6J"


preferred_country_code = symbol_conversion.CountryCode.USA,


asset_class=[


    symbol_conversion.AssetClass.FUNDS,


    symbol_conversion.AssetClass.EQUITIES,


    symbol_conversion.AssetClass.CERTIFICATES,


    symbol_conversion.AssetClass.BONDS,


    ],


asset_state=symbol_conversion.AssetState.ACTIVE,

).get_data()

ld.close_session()

response = pd.DataFrame(response.data.df).reset_index().rename(columns={'index': 'Ticker'})

print(response)

Is there something wrong with my code? Or this should be checked by content team?

Im looking for an API that will return me RICs for given ISIN.

ISIN's will be for Euro/UK FI Bonds.

I reached out to LSEG helpdesk via email, and they provided me with the following sample python code.

I am interested in Dotnet version of the below python API. And looking at the site, looks like there is "LSEG Data Library for .Net".

So just to confirm, this .Net API is basically same as below python API, and will return RIC for a given ISIN? Is there a REST API for the same?

Please let me know. Thanks

import lseg.data as ldimport pandas as pdld.open_session()ld.discovery.search(              view = rd.discovery.Views.FIXED_INCOME_QUOTES,query = "91282CNX5",top = 100,select = "RIC") 

ABX.TO is listed in Toronto Exchange

the RIC which the Exchange is United States is RIC B.

I have managed to create this code:

import refinitiv.data as rd

rd.open_session()
rd.discovery.search(
    view = rd.discovery.Views.EQUITY_QUOTES,
    top = 10,
    filter = "(AssetState ne 'DC' and SearchAllCategoryv2 eq 'Equities' and (RCSExchangeCountry xeq 'G:6J' and DTSubjectName in ('Barrick Mining')))",
    select = "DTSubjectName,ExchangeName,RIC,IssueISIN,Gics,AssetState,BusinessEntity,PI,SearchAllCategoryv3,SearchAllCategoryv2,SearchAllCategory,RCSExchangeCountryLeaf,RCSExchangeCountry"
)

Where the filters is Country of Exchange: United States and Name that contains: Barrick Mining.

But a code where we can enter the RIC and it will convert it into its US counterpart is more efficient to client since he may need to convert a list of identifiers and not just a single security.

I was wondering how I could get the ISIN for security types other than Equities such as futures or commodities? For example, I'm looking to find the ISIN for the RIC ESU25. Based on the github examples, I can only get the ISIN for equities.

Is there a way using the LSEG API to pull company data based off of the Ticker and not the RIC?

I tried doing it on my end using AAPL instead of AAPL.O and I encountered an error.

import refinitiv.data as rd
rd.open_session()
df = rd.get_data(
universe = ['AAPL'],
fields = [
'TR.PriceClose(Frq=D,SDate=2025-07-21,EDate=2025-07-28)',
'TR.PriceClose(SDate=2025-07-21,EDate=2025-07-28,Frq=D).date'
]
)

display(df)

Thank you team for checking on this matter.

I'm working with the LSEG Symbology API and running into an issue when trying to resolve the ODAX instrument using the ExchangeTicker identifier type. The same approach works fine for FDAX, but with ODAX, the request times out.

Here's a simplified version of the request body I'm using:

var requestBody = new
{
from = new[]
{
new
{
identifierTypes = new[] { "ExchangeTicker" },
values = new[] { instrumentCode }
}
},
to = new[]
{
new
{
identifierTypes = new[] { "RIC" }
}
},
type = "auto",
reference = new[] { "name", "status", "PermID" },
filter = new { status = "active" }
};

The instrumentCode is dynamically passed in, e.g., "FDAX" works perfectly, but "ODAX" causes the request to time out.

Am I missing something specific about how options like ODAX should be structured in the Symbology API? Is there a limitation in resolving option instruments this way, or does it require a different identifier type or additional metadata?

Any insights or examples would be greatly appreciated.

Thanks!

However, I tested it with other SEDOL, it is able to convert SEDOL to RIC.

Those unavailable assets are mainly ETFs, and I wonder is this the reason that cause the issue, thank you.

• I tried to use the library lseg.data.content.symbol_conversion, but it seemed that I don't have access to a scope to use this endpoint (trapi.search.lookup.read)  
• So I tried to requested directly by using the endpoint, through lseg.data.delivery.endpoint_request, by using the documentation here, https://github.com/LSEG-API-Samples/Example.DataLibrary.Python/blob/edb017dcc81caa605627557bc0116b81af4c75ed/Tutorials/3.Delivery/3.2-Endpoint/TUT_3.2.01-EndPoint-Overview.ipynb.
  I found this endpoint, https://api.refinitiv.com/data/symbology/beta1/convert, in the catalog here, https://apidocs.refinitiv.com/Apps/ApiDocs#/details/L2RhdGEvc3ltYm9sb2d5L2JldGEx/L2NvbnZlcnQ=/GET/PLAYGROUND, which seems to need the scope trapi.data.symbology.read, which is available with my account, but it still not working.

Can you help me with that, please?

Thanks a lot

I am using Tickers as you can see below but they are not matching with the RIC code. How I can get the data from LSEG with my Tickers?