Eikon Data API

Eikon Data API Usage and Limits Guideline

Overview

The Eikon Data API provides access to certain Eikon data. Your access and use of Eikon, including the Eikon Data API and any data included therein, is subject to the terms and conditions of your organization’s agreement with us. Eikon is an information service that is licensed for individual use and requires a log in session. A log in session controls entitlements and reasonable use for a single user. In line with single user workflow demands, the Eikon Data API imposes limits to ensure that our overall platform can sustain the usage rates of all individual Eikon users accessing data via APIs. This document briefly describes these various limits and the user experience when users hit them. Actual values for each of the limits described not contractual and do not engage Refiitiv in any way. These limits are subject to change at any time without notice. You are solely responsible for providing all necessary support with respect to any applications that you develop using the Eikon Data API. Note: If you wish to resell or redistribute any applications which you develop using the Eikon Data API to third parties, you must enter into a  developer's license agreement with us.

Limits at a Glance

License Eikon is only licensed for individual use. Eikon users may not share their login credentials, run any instances of Eikon on a server or use, distribute or redistribute data in any way that is inconsistent with their organization’s agreement with us. In addition, Eikon users may not use information in any manner that would violate rules or policies set by Third Party Providers.
Call Limits API calls can be limited based on number of requests made or the quantity of data received
Daily Limits Limits can be hit based on number of requests made or quantity of data received in a given day
Content Restrictions Content limits are controlled by entitlements and are set based on the product variant and add-ons purchased

What are the detailed limits?

Call-based Limits

  • Requests per second - The number of requests sent to the platform via the Eikon Data APIs cannot exceed this limit. This number of requests is counted across all client applications connected to the same Eikon instance. For example if 4 applications connected to the same Eikon send 1 request per second, the throttling mechanism will consider an aggregated rate of 4 requests per seconds.The current limit value (10-Oct-2019) is 5 requests per second.
  • Response volume per minute - The volume (size) of data retrieved from the platform via the Eikon Data APIs cannot exceed this limit. This volume of data is counted across all client applications connected to the same Eikon instance. The current limit value (10-Oct-2019) is 50 MB per minute.
  • Datapoints returned per request - A datapoint is a 'cell', or a unique field value for a unique instrument on a unique time stamp. Datapoint limits vary by the content set being retrieved (for example, timeseries limits are different from news headline limits), but all are throttled on a per request basis and are not aggregated across all applications. Here are Datapoint limit examples per Eikon Data API function type 
    • get_data: The limit value is around 10,000 data points for version 1.0.2 and below. No enforced limit for version 1.1.0 and above. However, it still has a server timeout around 300 seconds.
    • get_timeseries: The current limit value (10-Oct-2019) is 3,000 data points (rows) for interday intervals and 50,000 data points for intraday intervals. This limit applies to the whole request, whatever the number of requested instrument.
    • get_news_headlines: The current limit value (10-Oct-2019) is 100 headlines per request. The depth of history is 15 month.
    • get_news_story: The current limit value (10-Oct-2019) is 1 story per request.
    • get_symbology: No enforced limit (10-Oct-2019).

Daily Limits

  • Requests per day - The number of requests sent to the platform per day via the Eikon Data APIs cannot exceed this limit. This number of requests is counted across all client applications connected to the same Eikon instance.The current limit values (10-Oct-2019) are 10,000 requests per day and 5 requests per second.
  • Response volume per day - The volume (size) of data retrieved from the platform per day cannot exceed this limit. This volume of data is counted across all client applications connected to the same Eikon instance.The current limit values (10-Oct-2019) are 5 GB per day and 50 MB per minute.

Content/Entitlement Limits

  • Eikon Variant - Eikon API content coverage follows the Eikon Variant model and any add-ons that have been added to that Variant. For example, access to specific content sets available in the Eikon Premium Variant may not be available in Eikon for Research and Advisory, and therefore the same limitations would be enforced on the Eikon API.
  • Depth and Breadth of Content - Any content depth (like years of historical data) and content breadth (like the number of news sources or exchanges) available via Eikon and through Eikon apps like Eikon Excel, is for the most part also available in the Eikon API. There may be additional Eikon API limitations imposed by the providers of the underlying content. Consult this page for these additional Third Party Provider terms.

Platform/Infrastructure Limits

  • Overall concurrent request load - When the platform is overwhelmed by the number of requests it receives, it may take more time than usual to respond. When that happens, a timeout expires and the platform responds to the request with an error. It is important to note that the overloading may be due to requests sent by users other than the one who receives the error.

What happens when a limit is reached?

For Call-based and Daily limits, when the limit is reached, the Eikon platform returns an HTTP response with status code 429 and the message "Too many requests, please try again later.". Then, the Python library raises an EikonError exception with the following message:

When the limits for datapoints per request are reached, responses are simply truncated and only the available cells/headlines/results are returned - even though your request would have yielded a bigger response. For example, a news headline query may have yielded more headlines than those returned on the response, or a timeseries call could return a fewer number of years than what was requested.

If your Eikon Variant or additional entitlements do not include access to the Eikon Data API, your applicaiton may receive an HTTP response with status code 403 and the message “Your Eikon account is not allowed to run Eikon API Proxy.”. Then, the Python library raises an EikonError exception with the following message. It is recommended to contact your account manager if you get this error:

When a request fails because the platform is overwhelmed, an HTTP response with status code 400 and the message "Backend error. 400 Bad Request" is returned. Then the Python library raises an EikonError exception with the following message:.

What can be done when a limit is reached?

There is not a common behavior that every application should necessarily implement to deal with limits. What an application must do when a limit is hit is dependent on the goal of the application. Each application is unique in this domain. However, the following guidelines may help developers to define the right behavior for their applications.

Do not silently discard Eikon Exceptions

Each time a limit is reached, the function call that hits the limit (get_data, get_timeseries…) throws an exception that conveys important additional information to your application. If you just discard the exception the user of your application will not know that the request failed and that the data may be incomplete. The exception and the information it conveys helps your application to inform the user and to behave appropriately, for example by re-requesting the data.

Tell your user a limit has been reached

It is important to give your users an appropriate and accurate feedback about what happens in your application. When it comes to throttling limits, the feedback your application should give really depends on the limit the application hit. For example, if your application reached a Daily Limit, you could display a message in a dialog box that explains that a daily limit has been reached and that the application will stop receiving data until tomorrow. On the other hand, if an instant Call-based limit is reached, you may not want to display a message box each time it happens. Sending feedback via a transient and non-blocking visual way is probably more appropriate. For example, an instant limit reached could be represented by a different color that fades away progressively or a progress bar that indicates the time to wait. In the case of instant throttling limits, doing nothing could even be an option if your application is able to resend throttled requests automatically.

Consider leveraging the information sent along with the exception

The information that comes with the exception provides useful indications that help your application to behave appropriately. This information can be used by your application to decide on the most appropriate way to send feedback to the user (Dialog box, transient message, color or progress bar), but it can also be very useful to improve the user experience. For example, thanks to the “time to wait” information, the application can automatically resend requests that fail at the appropriate time.

Try to detect and address datapoint limits

It is not easy to detect when a datapoint limit is reached because in such situations Eikon does not send errors but just truncates the data it returns. This can be spotted visually by the user but also programmatically. For example, your code should check that the returned response covers the time span or any other dimension specified in the request (for example, if the request asked for 5000 instruments, but only 3000 were returned). When a datapoint limit is reached, the application can try splitting the initial request into smaller requests and resending them. Smaller requests can be built by reducing the number of instruments or by requesting shorter periods of time for time series. If your application is not able to resend smaller requests it should tell the user the data is not complete either by displaying a message, showing a visual indication, or by any other mean that is appropriate for your application.