Budget: 1000 UAH Deadline: 2 days
Good day! I have encountered exactly this — 429 appears because Power Query pulls the entire history again each time. I will rewrite the M-query for incremental loading using timestampModifiedAfter and add a retry with backoff, so it doesn't fail on 429 but waits and continues. One question: will you provide access to your Tovuti (key + test report) here so I can check the fix with real data? I will do it quickly.
Budget: 2000 UAH Deadline: 1 day
Hello!
I am ready to take on your project and will complete it urgently.
I have extensive experience with similar tasks, and there will be no difficulties.
If I have piqued your interest, feel free to write; I am happy to collaborate!
Budget: 2500 UAH Deadline: 3 days
Good day! We do exactly these types of integrations with REST API — your 429 is classic: the request pulls the entire history of courseProgresses each time, and it has exceeded the Tovuti limit.
What I will do:
1) I will rewrite Power Query (M) for incremental loading — we will only pull new/modified records through timestampModifiedAfter, not the entire history. The model with 4 tables (Teams, Courses, Users, AssignmentsProgress) and the relationships teamId/courseId/userId will remain unchanged.
2) I will add retry/backoff for 429 (try...otherwise + Function.InvokeAfter with increasing pause), so that the updates do not fail but gently wait for the limit and continue.
3) I will check on your real Tovuti API that the refresh passes, and briefly document what and why I changed — so you can maintain it further.
I have experience with M/incremental refresh, REST API (pagination, date filters, limits, backoff), and reading OpenAPI schema. I communicate fluently in English, so communication is not a problem.
One clarification regarding the essence: does courseProgresses return data with cursor pagination or only with date filter + offset? And will you be able to provide access to the .pbix and a key to Tovuti (a test one is fine) so I can test the fix on live data, not blindly — this is the fastest way to a working result.
The price is 2500 UAH, approximately 3 days from the moment of access. I am taking it at the starting rate — I am gathering initial reviews on Freelancehunt, so I am making it advantageous. I am ready to show our approach on a call/in correspondence before the solution.
Petro Pankov, BotCraft Group
Budget: 18000 UAH Deadline: 4 days
We can take this as a fixed task - a benchmark of 4 working days and 18,000 UAH. Essentially, it's not just about resolving 429, but reworking the loading of AssigmentsProgress so that Power BI doesn't loop through the entire history. Yes, API limits like to remind you of themselves at the least poetic moment =)
I would do it this way - separately extract the function for querying courseProgresses with pagination, add timestampModifiedAfter, a proper retry/backoff for 429, control for empty pages, and a brief description of the logic in M code. After that, I would check the updates on the real Tovuti API and go through the links teamId, courseId, userId, to avoid breaking the model of Teams, Courses, Users, and AssigmentsProgress.
Clarification, so as not to shoot sparrows with a cannon - do you have Power BI Pro or Premium, and is the standard incremental refresh used through RangeStart/RangeEnd, or is everything currently done only within Power Query? Secondly, in Tovuti, does timestampModifiedAfter return all modified records consistently in UTC, or is it the local time of the account?
> https://business.ingello.com/platforma - close in logic to a corporate platform where a stable data structure and process support are important
> https://business.ingello.com/forma-bpm - similar in approach to business processes, relationships between entities, and controlled automation
> https://business.ingello.com/vorfahr - an example with integrations and automation, where the reliability of data exchange is crucial
Briefly about us - Ingello Systems creates business systems, integrations, CRM, automation, and reporting, where a data error costs more than a proper architecture. The main landing page for the exchange - https://systems-fl.ingello.com/ua
To start, we need the current Power BI file or M code of the problematic table, an example response from courseProgresses, authorization parameters for the Tovuti API, and a brief explanation of how the update is currently triggered. Look, there's a nuance here - if the historical array is already large, it might be better to make one control full snapshot, and then only track incremental changes. This reduces the risk that we fix 429 but leave a slow model for the future.
Budget: 1500 UAH Deadline: 2 days
Got the task: the Power Query call for AssigmentsProgress is currently pulling the full history on every refresh and hitting Tovuti's 429 limit, and it needs to switch to incremental refresh using timestampModifiedAfter, plus retry and backoff on 429.
Honest note upfront: I haven't worked with Power Query M specifically before. My background is Python backend with heavy REST API experience, pagination, rate limits, retry and backoff patterns are exactly what I deal with daily, so the logic here is very familiar even if the M syntax itself is new to me. M is a small, well-documented language and the pattern you need, a parameterized incremental pull plus a backoff wrapper, is straightforward once I look at your current query.
What I'd do: add a stored parameter for the last successful refresh timestamp that feeds timestampModifiedAfter into the courseProgresses call, wrap the API call in a retry function that catches 429, waits, and retries instead of failing the whole refresh, and test it against your live Tovuti data before handing it back with a short writeup of what changed and why.
If you're open to it, I'd also suggest storing the last-refresh timestamp outside Power BI so it survives even if a refresh partially fails, rather than deriving it purely from existing data — happy to discuss once I see the current query.
Given it's one query with a defined pattern, this is realistically a 2-3 day task including testing against your real API.
Budget: 8000 UAH Deadline: 3 days
We have experience optimizing API requests in Power Query to bypass limits. We implement this through the introduction of caching mechanisms and batch processing logic to avoid error 429. This will ensure the stable operation of your reports without exceeding Tovuti LMS limits. We are ready to start setting up the integration soon.
Budget: 5000 UAH Deadline: 4 days
Hello, Olga!
The task is clear: the report is constantly overloading the entire history of courseProgresses, the volume has exceeded the Tovuti limit — hence the 429. We need to convert the fact table AssignmentsProgress to incremental loading and teach the query to handle the limit instead of failing.
How I will do it:
• I will rewrite the query in Power Query (M) so that courseProgresses pulls from timestampModifiedAfter — only new/modified records since the last update instead of a full backfill.
• I will add a retry/backoff wrapper: on 429 the request pauses with increasing intervals and retries (with a limit on attempts), plus correct pagination.
• I will test on your real Tovuti API to ensure the refresh completes and the links between Teams/Courses/Users remain intact.
• I will briefly document what and why has been changed so you can maintain it yourself.
Two clarifications:
Where to store the "starting point" for timestampModifiedAfter — a separate parameter, or do we do a full backfill once, then only incremental?
Is the refresh done through Power BI Service (on a schedule) or Desktop? This affects how to make the date stable between updates.
The timeline is 3–4 working days including testing on your API. The price is fixed, approximately 5,000 UAH; I will finalize after your responses above.
Budget: 1000 UAH Deadline: 1 day
Good day! I am ready to fix this error!! I can do it tomorrow!!!
Budget: 1111 UAH Deadline: 1 day
Good day!
I have experience working with Power BI, Power Query (M), and REST API integrations. I understand the problem: due to the full loading of the API history, it hits the request limit, so the optimal solution is to switch to incremental refresh.
After reviewing the current Power Query and API, I will be able to assess the timelines and propose a fixed cost.
Budget: 27000 UAH Deadline: 5 days
We already have a practically ready similar solution for incremental data updates via API, which can be quickly adapted for Tovuti LMS and Power BI.
Regarding the estimate - 28,000 UAH and approximately 5 working days after access to the report, test API, and current Power Query logic.
I will work not just with error 429, but with the cause - a complete reload of the history in AssignmentsProgress.
> I will move the loading of courseProgresses to an incremental model via timestampModifiedAfter.
> I will add pagination control, API limits, and retry/backoff for 429.
> I will check the connections with Teams, Courses, Users, and AssignmentsProgress to ensure the model does not break after the query changes.
> I will briefly describe what has changed and how to support it further.
Look, there’s a nuance - we need to agree on where exactly to store the last timestamp for updates. In Power BI, this can be done in several ways, and it’s better to choose one that won’t create surprises during publication and scheduled updates in the service.
Please clarify:
> Is the report updated in Power BI Desktop or already through Power BI Service?
> Is there a stable modified/updated field for courseProgresses in Tovuti that accurately corresponds to timestampModifiedAfter?
Relevant examples of our work:
> https://business.ingello.com/forma-bpm - automation of business processes and data, close to the logic of the supported system.
> https://business.ingello.com/iks - corporate system with accounting, roles, and analytics.
> https://business.ingello.com/vorfahr - an example of more complex automation with integrations and data.
The main profile of Ingello for the marketplace - https://systems-fl.ingello.com/ua.
We can discuss the details here, I’m available. Overall, it’s a normal task, but the devil, as always, is in the update dates and Power BI cache.
