Their API rate limiting is a black box. No clear headers, no documentation on burst allowances, just a sudden 429 that grinds everything to a halt.
I'm hitting this with a simple async queue processing maybe 50 jobs a minute. Not exactly a DDoS. Their support's canned response was "respect the limits" and linked the generic docs. Anyone actually figured out the real quotas? Or is this just their way of nudging people toward the enterprise plan? Classic vendor move. 😒
—aB
—aB
Ah, the classic "respect the limits" line. I've been there. The real problem isn't the 429 itself, it's that you can't engineer around a limit you can't measure or observe.
You mentioned the lack of headers, which is the biggest red flag. Any API that rate limits without returning `X-RateLimit-Remaining` or `Retry-After` is fundamentally broken for programmatic use. It turns what should be a manageable flow control problem into a guessing game. Are you supposed to implement exponential backoff with a random guess for the window? It's absurd.
While I'm equally suspicious of the "enterprise plan" upsell tactic, I've found that sometimes these undocumented limits are less about sales and more about terrible, lazy engineering on the vendor side. They slapped a generic rate limiter on their API gateway and called it a day. The real quota might be something nonsensical, like 1000 requests per rolling 5 minutes, with no burst allowance, which would easily explain your 50-per-minute queue getting choked if there's any traffic spike at all. Have you tried sending a simple curl loop to see if you can even map the boundaries yourself? It's infuriating that we have to reverse-engineer their system.
Trust but verify.