Skip to content
Notifications
Clear all

Breaking: API rate limits quietly changed. Now throttling after 100 calls/hour.

1 Posts
1 Users
0 Reactions
2 Views
(@frankd)
Eminent Member
Joined: 4 days ago
Posts: 23
Topic starter   [#20543]

Heads up to everyone using Fireflies.ai's API in production workflows. I was running some routine vendor performance monitoring this morning and noticed a spike in failed syncs from our procurement dashboard. After digging into the logs, it looks like Fireflies has quietly updated their API rate limits without any announcement or update to their public documentation.

The old limit was a generous 600 calls per minute, which was more than enough for most batch processing jobs. The new limit appears to be **100 calls per hour**. That's a massive reduction—from 600 per minute down to roughly 1.6 per minute. This isn't just a tweak; it fundamentally changes what you can automate.

Here’s what I confirmed through testing and a brief, unhelpful support ticket:
* The throttling error (`429 Too Many Requests`) now kicks in consistently after the 100th call within a rolling 60-minute window.
* The `X-RateLimit-Limit` and `X-RateLimit-Remaining` headers are present in responses, which is good, but the limit stated there is the new 100/hour.
* This affects all endpoints, not just transcription requests. Calls to fetch meeting lists, get summaries, or update topics all count toward the limit.

This is a serious problem for anyone with more than a handful of daily meetings. Consider a simple workflow: fetching transcripts for 50 sales calls at the end of the day, then making a second call per meeting to retrieve the summary. You've already hit the limit. If you're doing any sort of vendor risk assessment that requires pulling large sets of historical data, you'll be throttled almost immediately.

I'm bringing this here because:
1. **Transparency:** Quiet changes to core API limits that break existing workflows are a major red flag in vendor management.
2. **Impact Assessment:** We need to collectively understand who this hits hardest. Is it just high-volume users, or does it cripple even moderate use cases?
3. **Workarounds:** Has anyone devised a strategy? We're now looking at implementing aggressive queuing with delays, which defeats the purpose of near-real-time analysis.

My immediate advice is to audit your integration's call volume and start implementing exponential backoff logic if you haven't already. I'd also recommend everyone check their SLA agreements—if you have one—to see if this constitutes a material change in service levels.

Has anyone else run into this? More importantly, has anyone received official communication from Fireflies about the change or its rationale? I'm concerned this is a cost-cutting move that significantly degrades the value of the platform for automated procurement and compliance auditing.

— frank


buyer beware, but buy smart


   
Quote