Potential retirement of the “UDF” service and RIC request limits

Question

A client was told there's a potential retirement of the “UDF” service in September. Is this correct and is it a firm deadline?

His other question is due to RIC request limits.

How people are supposed to use the “new” library when each data load request appears to kick off an underlying request per-ric.  Meaning a 100 RIC request for data uses 100 requests of quota rather than 1 as in the “old” library.

A. new “lseg data” library"

https://developers.lseg.com/en/api-catalog/lseg-data-platform/lseg-data-library-for-python

B. old “Eikon” library (that works with Workspace using “UDF” in the background)

https://developers.lseg.com/en/api-catalog/eikon/eikon-data-api/documentation

Jirapongse · Answer

@janet.littleton

It depends on the endpoints that the library uses to retrieve data. If the data comes from the Historical Pricing API (HPA), note that HPA supports only one RIC per request when retrieving time series data. As a result, requesting historical data for 42 RICs typically generates 42 request messages. HPA provides historical data for real-time fields, such as TRDPRC_1, BID, and ASK.

If a client requests historical data (HPA) for 300 RICs in a single ld.get_history() call, it will be counted as 300 request messages. Based on this limit, the code can call ld.get_history() with 300 RICs approximately 33 times before reaching the request threshold.

The same limitation applies to all Workspace Desktop users. This limit is in place to help ensure compliance with data usage policies and contractual terms.

janet.littleton · Answer

The client provided the below example. The WS specialist said it's per data pull not a sum of all the RIC pulls. So, its per data pull and that specific data pull total. Can you confirm using the client's example below that he should not hit the 10K daily limit? I don't want to give the client the wrong information. Thanks!

As a concrete example, querying

rics=['AUDON=', 'AUDSW=', 'AUD1M=', 'AUD3M=', 'AUD6M=', 'AUD1Y=', 'CADON=', 'CADSW=', 'CAD1M=', 'CAD3M=', 'CAD6M=', 'CAD1Y=', 'EURON=', 'EURSW=', 'EUR1M=', 'EUR3M=', 'EUR6M=', 'EUR1Y=', 'GBPON=', 'GBPSW=', 'GBP1M=', 'GBP3M=', 'GBP6M=', 'GBP1Y=', 'JPYON=', 'JPYSW=', 'JPY1M=', 'JPY3M=', 'JPY6M=', 'JPY1Y=', 'MXNON=', 'MXNSW=', 'MXN1M=', 'MXN3M=', 'MXN6M=', 'MXN1Y=', 'NZDON=', 'NZDSW=', 'NZD1M=', 'NZD3M=', 'NZD6M=', 'NZD1Y='] for 30 minutes of 1-minute-bar price data would use 42 requests not 1.

The client thinks it means the below:

That is a fundamentally different set of request limits.  For futures, I often request data for 200-300 RICs at a time à thus 10k requests per days actually becomes 33 requests per day (10000 / 300 ~= 33).

Jirapongse · Answer

@janet.littleton

Typically, a limit of 10,000 requests is sufficient for most desktop user use cases. If a user requires more than 10,000 requests per day, they should contact their LSEG account team or sales representative to discuss their requirements and explore available options.

EXPLORE OUR SITES