Several topics have already been created regarding the 429, but the explanations vary. That’s why I’m creating a separate topic for my own situation.
I’m on an intake OEM account and have been frequently encountering the 429 error messages for multiple databases over the past few days.
Can you see if there’s anything wrong with my configuration, or perhaps my account?
Coincidentally, I received my first invoice this week, I don’t know if that could have something to do with it?
What text appears when you click on “Path” at the displayed URL and authenticate in the browser?
Thank you for the quick response. My live and history monitoring is completely empty (even though activities have been carried out, and also if I select multiple entries per page) so I can’t perform the above.
This is also new to me by the way; normally the history would return perfectly here.
If the generic link can be sent, I can adjust it with the correct database name.
{
"error": {
"code": "itgenboe405",
"message": "The daily limit of 3,600,000 ms of duration from cache has been exceeded by 15,374,848 ms.",
"target": null,
"details": [
{
"code": "TraceIdentifier",
"target": null,
"message": "0HNM205IHUBV1:00000001"
},
{
"code": "Name",
"target": null,
"message": "TotalDurationMsPerDay"
},
{
"code": "LimitValue",
"target": null,
"message": "3600000"
},
{
"code": "CurrentValue",
"target": null,
"message": "18974848"
},
{
"code": "RemainingValue",
"target": null,
"message": "0"
},
{
"code": "RemainingDurationWindowSec",
"target": null,
"message": "29510"
},
{
"code": "LifetimeSecFromUtc",
"target": null,
"message": "86400"
},
{
"code": "SessionId",
"target": null,
"message": "user-ab84ed3c-6881-4976-8163-8826889b4089"
},
{
"code": "DatabaseUid",
"target": null,
"message": "c004b18c-db00-410d-b3df-7b5a7488aab4"
},
{
"code": "SubscriptionType",
"target": null,
"message": "SUBOEMGRW"
},
{
"code": "SubscriptionCode",
"target": null,
"message": "L968699804"
}
],
"innererror": null
}
}
The itgenboe405 indicates that the total duration per day has been exceeded (TotalDurationMsPerDay).
The advice is to optimise the total duration of all requests. The allowed duration within this form is 1 hour, but there has been roughly 4 hours of continuous activity.
An overview of all error codes leading to a 429 can be found at:
Thank you for the response. Questions:
Incidentally, I also find the duration quite long, especially since my clients have a few tables of around 400k (2 or 3) and the rest are all small dimensions. Refresh times on a full load take about 30-45 minutes.
Is there anything that can be done on the configuration side of the database to speed this up? Page sizes, for instance?
It’s about the duration of the request. This 1 hour applies to the entire environment covered by the plan.
When dealing with 1 to 2 million rows, this should easily be possible within 1 hour on most platforms.
The advice is to optimise the queries.
From release 26.0.100, it’s also directly visible in Monitoring what the cause of the limit exceedance is:
In this example itgenboe655 is visible. The corresponding translation is not yet available but will be within a few days.
Under “Possible solutions”, it’s also visible where the documentation can be found, specifically here.
Ok, so I see it’s the number of API calls per day. However, does this apply per database? Or is the limit applied to all databases once it’s exceeded anywhere?
All limits apply across all activities of an environment, including databases.
Generally, the limits are very generously allocated. Should you still encounter them, it’s advisable to identify which actions are disproportionately consuming the limits and optimise them.
I have looked at the monitoring output and indeed see considerable duplication, but looking at my own code in Power BI, the code itself is not inefficient but the inherent design of Power BI:
For each query, metadata (odata4/$metadata) is requested again, even though it’s the same metadata. Staging tables are not possible either, which means each query sends a new request to Invantive. For example, for the sales order table (ExactOnlineREST.SalesOrder.SalesOrderLines@eol):
| 09-06-2026 01:10:21 |
| 09-06-2026 01:13:40 |
| 09-06-2026 01:15:11 |
| 09-06-2026 01:18:30 |
| 09-06-2026 01:20:01 |
Given that the connector is intended for Power BI and this is an inherent problem with the way refreshing works in PBI itself, I’m not sure what I can do.
Additionally, the point: If the cap applies to my entire environment on OEM, and there are 4 clients under it each with a daily refresh, then I reach that cap much faster than if these 4 clients had their own accounts. Yet, I pay the same as those 4 clients added together. Right?
Each refresh per environment lasts about 1500 seconds, which is fine with a cap of 10k. With 4 environments (and I hope to add more), this is 6000 per day. With development and possibly an additional refresh moment during the day, I quickly exceed that 10k.
Advice:
SalesOrderLines@eol to a bulk or incremental table. This can reduce the duration by a factor of 1,000.The limits for a regular OEM plan are significantly higher than for a regular plan.
Thank you for the answer. I used SalesOrderLines instead of the bulk because there are some columns in the non-bulk version that are not present in the bulk version. However, I was able to significantly speed things up by applying filtering earlier. I will also do this for other queries to prevent folding from breaking.
Another major contributor to refresh time is ‘odata4/$metadata’. Is there anything that can be done about this, or is it inherent to the number of queries being run?
If everything is correct, then all fields of SalesOrderLines should also be found in SalesOrderLinesBulk and vice versa. Which specific fields are missing?
Fetching the $metadata should only take a few milliseconds after the initial retrieval. It is advised to check that not too many concurrent requests are running, causing them to have to wait longer.
The following fields are present in SalesOrderLines, but not in SalesOrderLinesBulk:
| Field | Description |
|---|---|
CustomField |
Custom field payload |
DeliveryStatus |
Line delivery status |
InvoiceStatus |
Line invoice status |
OrderStatus |
Order status on the line |
Margin |
Line margin |
QuantityDelivered |
Delivered qty |
QuantityInvoiced |
Invoiced qty |
TaxSchedule |
Tax schedule (GUID) |
TaxScheduleCode |
Tax schedule code |
TaxScheduleDescription |
Tax schedule description |
I am particularly interested in the invoice and delivery status fields.
From release 26.0.285, the time reported for code itgenboe405 will no longer include the waiting time, but only the execution time. This increases the available space, especially if a process has gone off track or if there are many requests at the same time, some of which need to wait.
This question was automatically closed after 1 week of inactivity. The last given answer was marked as the solution.
Please post a new question in a separate topic if the issue recurs. Please include a link to this topic in the new question by pasting its URL into the text.