Method 1:

Check Usage Limits via the endpoint

When your application uses a desktop session, you can query the DAPI throttling endpoint (localhost:<port>/api/throttling/limits) to retrieve the current usage limits and remaining quota.

For example, open:

http:// localhost:9001/api/throttling/limits

(Remove the space before localhost when using the URL.)

The response will be like below

Understanding the Response

The response contains information about both request-based and volume-based usage limits, including the configured limits and the remaining quota available to your application.

The fields are described below:

• daily_request_max – Maximum number of requests allowed per day.
• daily_request_remaining – Number of requests remaining in the current day.
• request_max – Maximum number of requests allowed within a throttling period.
• request_remaining – Number of requests remaining in the current throttling period.
• request_period – Duration of the request throttling period, in seconds.
• daily_volume_max – Maximum daily data volume allowance.
• daily_volume_remaining – Remaining daily data volume allowance.
• volume_max – Maximum data volume allowed within a throttling period.
• volume_remaining – Remaining data volume available within the current throttling period.
• volume_period – Duration of the volume throttling period, in seconds.

For example, in the response above:

• request_max: 5 and request_period: 1 indicate that up to 5 requests per second are allowed.
• request_remaining: 5 means the application has not consumed any requests within the current one-second window.
• daily_request_remaining: 9999 indicates that 9,999 requests are still available for the current day.

Monitoring these values can help applications proactively manage request rates and avoid encountering HTTP 429 (Too Many Requests) errors when usage limits are reached.

Method 2

Check Usage Limits via HTTP Response Headers: This method uses Workspace debug logging and HTTP response headers to inspect usage limit information returned by the platform.

Step 1: Enable Debug Logging in LSEG Workspace

1. Open the Configuration Manager in your LSEG Workspace Application.

2. Navigate to the Logs page under the Advanced section.

3. Set the Trace Level to Debug, then click Apply (see screenshot below)
Note: Setting the trace level to Debug may impact system performance. Use this level only when troubleshooting or monitoring usage.

4. Click OK to apply the configuration and Restart LSEG Workspace to activate the changes.

Step 2: Configure Logging in Your Python Script

You can set the log level to debug either in your configuration file or directly in your code. Here’s the example configuration file: (see more detail and example of configuration file here)

And here's how to do it in-line:

Step 3: Monkey-Patch the Data Library to Log HTTP Response Headers

To print out the HTTP response headers (which often include usage and limit information), you can monkey-patch the request method in the HTTPService class:

Step 4: Run Your Data Retrieval Code

Now, when you run your Data Library functions to retrieve data, the HTTP response headers—including any limit or usage information—will be printed in your console log (or log file, depending on your configuration).

Step 5: Check Detailed Logs in Workspace

For more detailed information about your API usage and limits:

• Go to the Workspace Logs folder. The Full Path to it can be found in Logs section of Configuration Manager

• Open the most recently created sub-folder named like Desktop.<date>.<time>.p<process-ID>.
• Look for the file named node-sxs.<date>.p<process-ID>.log.
• Search for the lines that contains [DEBUG] DP Client::Limiter

Here, you can find additional details about your requests and any limit-related messages.

Conclusion

Monitoring your remaining usage quota can help you avoid unexpected interruptions and better manage your application's interaction with the Data Platform.

In this article, we covered two methods for checking usage limits in the Data Library for Python:

1. Querying the DAPI throttling endpoint when using a desktop session to view the current limits and remaining quota directly.
2. Inspecting HTTP response headers and Workspace debug logs to obtain detailed usage and throttling information returned by the platform.

By incorporating these monitoring techniques into your development and troubleshooting workflows, you can proactively detect when your application is approaching its usage limits, implement appropriate retry or backoff logic, and reduce the likelihood of encountering HTTP 429 (Too Many Requests) errors.

The sample Jupyter Notebook file for this article can be found in the top-right section of this article.