Vimeo API rate limits: what you'll hit during a migration
Image placeholder
Rate limit visualization
A technical-looking line chart or bucket diagram showing API requests over time hitting a ceiling. Could be a leaky-bucket visual (requests flowing in, capped output), or a time-series graph with a flat red line labeled 'rate limit'. Abstract enough to convey the concept without being too literal.
If you're migrating a Vimeo library via the API, the first thing that will surprise you isn't bandwidth — it's Vimeo's rate limiting. We've moved enough libraries at this point to have opinions, so here's what actually happens and how to work with it instead of against it.
Where the limits apply
Vimeo documents rate limits on their developer portal but the numbers in the docs don't always match what you'll see in practice. What we've measured:
- A per-token ceiling on calls per minute. For most tokens this is high enough that hand-written scripts don't notice it, but migrations do.
- A per-token daily quota. For very large libraries (1000+ videos), this becomes the hard ceiling.
- Burstable limits — short spikes over the per-minute ceiling are usually tolerated briefly, then rate limited hard.
What gets rate limited
Not the actual file downloads — those go through Vimeo's CDN and aren't API calls in the rate-limited sense. What's rate limited are the API calls you make to list your videos and fetch their metadata (including the file URLs you actually need to download).
This means a migration of a 100-video library makes roughly 100 rate-limited calls. A 1000-video library makes 1000. Getting the metadata is where your budget goes, not streaming the video bits.
How plan tier affects it
Higher-tier Vimeo plans get more generous quotas. In practice:
- Starter: fine for a few hundred videos, pauses start showing up for libraries over ~500.
- Standard: smoother for mid-size libraries (500-2000 videos).
- Advanced and Enterprise: mostly unbounded for practical migration purposes.
Try it now
Server mode handles rate limits automatically
Batching, pacing, and exponential backoff on 429s. Set it and forget it.
Try server mode→What to do about it
Three practical things:
- Batch your requests and pace them.Instead of firing 1000 metadata calls in parallel, space them out. Our server mode does this automatically — the reason server-mode transfers don't saturate your Vimeo API quota is request-pacing.
- Cache aggressively.For a one-shot migration, fetch metadata once and reuse it. Don't poll Vimeo for status mid-transfer; trust your own state.
- Consider upgrading briefly.If you're on Starter and trying to move a huge library, bumping to Standard or Advanced for one month can drop your migration time by a lot — the cost is less than the pain.
What we do
In server mode, we batch metadata calls, pace them, and retry with exponential backoff when we hit a 429. For large libraries, this means the migration is a steady stream rather than a burst — it takes a bit longer wall-clock than it would if Vimeo had no limits, but it completes without hand-holding.
Browser mode is subject to the same limits but with a smaller effective batch because of per-client parallelism. If you're on a very restrictive Vimeo plan, you may see browser-mode transfers pause mid-way. The transfer widget will show the pause and resume automatically.