Joerg Sto
Summary
After a token exceeds the 100 req/min limit, it isn't throttled for the rest of the minute — it's locked out for roughly 15 hours before calls succeed again. We'd like the post-429 cooldown reduced to a short window on the order of 60 seconds, consistent with the fact that the limit itself is defined per minute.
What happens today
  • A brief burst trips the 100/min limit and returns 429 (expected).
  • The token then stays locked for ~15 hours before it works again. We've hit this directly, and it isn't described on the rate-limits docs page.
Why this matters
The standard mechanism already does the job: a 429 plus a per-minute window lets a well-behaved client back off and retry shortly after. That's the whole point of a rate limit — smooth the burst, then carry on.
A ~15-hour suspension doesn't smooth a burst; it removes API access for the rest of the working day after a single overage. Functionally that's an outage, not a rate limit. It adds no protection beyond a short cooldown — the workspace is idle again seconds later — and any legitimate bulk job (a nightly sync, a reporting pull, a migration) that trips the limit once is knocked offline until the next day. That makes reliable automation on the platform hard to build.
Proposed change
Reduce the post-429 lockout to a short cooldown — on the order of 60 seconds. Since the limit is measured per minute, a one-minute cooldown is the natural, proportionate window: it fully absorbs a burst, still protects your infrastructure, and lets a correctly-built client recover automatically within the same minute. We're not asking to raise the limit — only to shorten the recovery time after it's tripped.
Here a little bit about "How this tastes..."
If there's a reason for a multi-hour lockout that we're not seeing, we'd be happy to hear it. In practice we've never encountered another product — API or otherwise — that responds to a per-minute rate limit with a full-day suspension, so if there's a justification, we'd like to understand it.
Behavior like this erodes developer trust in the platform (in my case that is already crumbling for a long time). When an undocumented, multi-hour lockout has no technical rationale we can identify, it inevitably raises the question of whether it's less about protecting infrastructure and more about discouraging external integrations — pushing customers toward ClickUp's own built-in AI and automation instead.
If that isn't the intent, the current behavior still creates exactly that impression — and candidly, your Brain/AI-Automation isn't delivering the value that comes close to what external integration can bring.
Looking forward to understand the reasoning and maybe I missed something!