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.
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 |
Call-based Limits
Daily Limits
Content/Entitlement Limits
Platform/Infrastructure Limits
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:.
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.
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.
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.
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.
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.