We've been using the Otter.ai API as part of a pipeline for benchmarking transcription accuracy across several models. Our workflow involved processing large batches of audio samples (hundreds to thousands of short clips) to generate comparative word error rate (WER) data.
This week, our pipeline began failing with 429 errors. Upon investigation, we confirmed the API rate limits have been significantly reduced without a corresponding update to the public documentation. The previously workable limits for batch operations are now untenable for any serious bulk analysis.
Our previous configuration, which processed a batch over a few hours, now requires days due to the need for excessive delays between requests. Here's a simplified version of our processing loop that now fails:
```python
# Simplified batch processor
for audio_file in large_batch:
# This now hits rate limits after a very small subset
response = otter.transcribe(audio_file)
results.append(calculate_wer(reference, response))
time.sleep(1) # Even with a sleep, we hit limits
```
The key constraints we've observed empirically:
* **Stricter requests-per-minute:** Appears to be roughly 1/3 of the previous threshold.
* **Reduced daily quota:** Our aggregate usage for a standard development account is now capped much lower, halting long-running evaluations.
* **Ambiguous error messaging:** The 429 responses do not clearly indicate retry-after timeframes, making graceful backoff challenging to implement.
This change effectively nullifies Otter.ai for any research or benchmarking use case requiring systematic, large-scale transcription. For those using it for bulk processing, what mitigation strategies have you found? Have you switched to another service's API for batch workloads, and if so, what has been your experience with their limits and consistency?
BenchMark
That's rough. We had something similar happen with a different API last month. Have you checked if there's a batch endpoint hiding somewhere? Sometimes they have a separate route for sending multiple items at once that isn't as limited.
Your loop with a 1-second sleep... yeah, if they dropped the RPM that much, you might need to implement exponential backoff with jitter. It's annoying but it kept our stuff from completely dying while we looked for another vendor. 😬
What are you using to orchestrate the pipeline? Just scripts, or something like Airflow?
The batch endpoint suggestion is a good one, but based on the public docs, Otter.ai doesn't have one. Their API structure is fairly linear.
Exponential backoff is the immediate technical fix, but it's just a band-aid. The core issue is vendor transparency. Changing operational limits without a documentation update or comms to active integrators breaks trust. It turns a technical workaround into a relationship problem.
What was the outcome with your other vendor? Did they offer a path for high-volume use, or did you have to migrate entirely?
—AF
Oof, that's frustrating. "The previously workable limits... are now untenable" is the worst part. Did your team try reaching out to their support directly to ask about bulk licensing or a special tier? Sometimes the public API limits are for standard accounts, but they have other options.
Also, for benchmarking, can you stage the audio files somewhere else and process them in parallel using multiple API keys from separate test accounts? Not ideal, but it might get your current batch done while you figure out a long-term fix.
What's the actual RPM you're seeing now versus before?
Still learning
Multiple keys from separate test accounts is clever, but wouldn't that violate their ToS? I've seen vendors get really strict about that.
Has anyone had luck getting a straight answer from Otter.ai support on the actual limit change? The lack of updated docs makes me wonder if it's an intentional policy shift or just a temporary scaling issue on their end.
What was the RPM before? That's the key metric to know how much you'd have to spread load.
> processed a batch over a few hours, now requires days
That's the real cost. Have you quantified the compute time for the pipeline itself, now idle waiting on API calls? The wasted machine hours will probably eclipse the API spend.
Your 1-second sleep is a guess. You need to actually test and log the 429s to find the new limit, then build a queue with that precise delay. Or better, run multiple benchmark jobs in parallel across different regions/VPCs if their limits are per-key.
We switched from a similar vendor when the math showed it was cheaper to run Whisper on GPU spot instances than pay for the throttled API calls. The break-even point might surprise you.
show the math
> The previously workable limits for batch operations are now untenable
I'm seeing this kind of thing happen more often. Have you checked if they changed the limit per endpoint or per API key? If it's per key, you could try setting up a small pool of keys and rotate them in your script. Not a real fix, but might get you past the immediate backlog.
Also, are you tracking the exact 429s in a log? You might be able to reverse-engineer the new limit (like, 20 requests per minute) and build a proper token bucket queue. That's what we had to do for a Cloudflare API project.
Sorry you're dealing with this. It's so frustrating when the docs aren't updated.