Just pulled the latest API docs. They've updated the rate limiting section without any announcement. The "per minute" limits for several endpoints have been reduced by 20-30%.
Check your project settings dashboards now. If you're running near capacity, you'll start hitting 429 errors.
Key changes I've confirmed:
* `POST /v4/videos` creation limit dropped from 120 to 90 per minute.
* `GET /v4/videos` and other list endpoints dropped from 300 to 240 per minute.
* The "burst" allowance appears to be gone from the documentation.
This is a significant throughput cut for automated workflows. If you're batching video generation or syncing assets to a CDN, your jobs will now take longer and may require additional error handling.
Example of the old vs. new logic you'll need:
```javascript
// Old logic with higher limits and burst
const delay = 60000 / 120; // ~500ms between calls
// New required logic
const delay = 60000 / 90; // ~666ms between calls
// Plus, you now need robust retry with exponential backoff for 429s
```
Has anyone else seen this impact their integrations yet? I'm recalibrating our migration timelines for two clients because of this.
Show me the query.
Ouch, that's rough. I had a similar silent change happen with a CRM API during a client migration last year. The sudden 429s caused a cascade failure in our sync jobs.
> your jobs will now take longer
This is the real kicker for project timelines. It's not just adding retry logic, it's a fundamental recalculation of your total processing window. For our batch job, it meant moving from a 4-hour nightly window to a 6-hour one, which bled into business hours.
One thing to watch for is client-side rate limiting libraries. Some of them might have the old burst logic or default intervals hard-coded. You'll likely need to bump their version or manually set the `minTime` between requests.
test the migration twice
Right? The timeline creep is the silent killer. That extra 2 hours you mentioned can blow a hole in your SLA.
Your point about client-side libs is spot on. I've seen SDKs cache those rate limit headers internally. Had a Python script using `ratelimit` that suddenly started queueing things wrong because the decorator still had the old `calls=120, period=60` baked in. Took a while to spot since the error handling was fine, the throughput just died.
Makes me wonder if they're prepping for a bigger user surge and needed to tighten quotas. Still, a heads-up would've been nice.
Totally feel the timeline pain. That 4-to-6 hour shift isn't just a longer runtime - it starts eating into your buffer for handling anomalies or scale. Had a similar thing happen with an Azure data pipeline last fall after they tweaged a quota. The project's monthly compute cost actually went up 15% because the job had to run into more expensive on-demand hours instead of staying within a reserved instance window.
Your SDK/library warning is huge. Found that some of the Go clients we used had the limits baked into the package-level constants. Had to fork and patch before the official vendor update came through months later.
Right-size everything