With the upcoming API limits being enforced, I wanted to confirm whether Toggl will continue using a leaky bucket rate-limiting system. Specifically, is it still acceptable to handle 429 Too Many Requests responses by backing off and retrying later?
We’ve built a system that syncs project data and time entries between our ticketing system and Toggl. With the new limits, it may become more challenging to keep this integration fully compliant.
Any clarification on how the new rate limits work—or recommended best practices for staying within them—would be greatly appreciated. Thanks!
Hi @hejdamax, there should be no change made to the leaky bucket rate-limiting approach. Also, I can now share that the limits originally communicated with our users via email will likely change, as well as the date when they will be implemented, due to user feedback. More info to come soon.
Thank you very much. I will await any news that will come. It would be a shame if Toggl became unusable for many people due to overly restrictive API limits.
@Support - Toggl needs to remove the limits NOW and rethink. The product is now utterly broken for even the simplest system integration use cases. We pay thousands a year for this product and are now seeking alternatives.
I’m a single individual doing nothing but changing tasks over the course of an hour. I have the Starter plan but I’m still hitting API limits after the 5th task or so. It’s very frustrating.
Well that’s not very nice. Seems like your costs wouldn’t increase much to have 200 instead of 30 per hour. What is even the business strategy for this? Annoy a percentage of your customers to get them to leave and find someone who won’t annoy them?
If you’re using the /me endpoint, our 30-request per hour limit per user applies to everyone, regardless of plan.