MVMNT API rate limits protect platform reliability and keep performance predictable for every broker, carrier rep, and integration running in production.
Rate limits vary by plan tier (Standard, Enterprise). If your integration needs higher throughput, talk to your MVMNT contact about Enterprise limits.
- How rate limit tiers work (Standard vs. Enterprise)
- How to read rate limit headers
- How to handle
429 Too Many Requests - How to avoid throttling in production
Rate limit headers in every response:
X-RateLimit-Limit- Your maximum requests per minuteX-RateLimit-Remaining- Requests remainingX-RateLimit-Reset- When limit resets
See API Overview for a brief overview.
Use the headers as a live view of how close you are to the limit:
X-RateLimit-Limit: the cap for the current time window.X-RateLimit-Remaining: how many requests you can still send before you’ll be throttled.X-RateLimit-Reset: when you can send at full speed again.
For debugging, capture headers with a request and keep them in your logs:
curl -i https://api.mvmnt.com/...A 429 Too Many Requests response means you exceeded the current window’s limit. Treat it as a signal to slow down, not as a transient network failure.
When you receive a 429:
- Stop sending more requests immediately from the same worker/pool.
- Read
X-RateLimit-Resetand wait until the reset point before retrying. - After waiting, resume with a lower request rate (or lower concurrency) so you don’t bounce between “ok” and “throttled.”
Avoid retry storms:
- Don’t retry all throttled requests at once. Spread retries over time.
- If you have multiple workers, coordinate so they share a single throttle budget instead of competing.
These patterns keep integrations stable under real broker workloads (batch imports, load tracking updates, quoting bursts):
- Client-side throttling: cap request rate and concurrency in your API client based on
X-RateLimit-Remaining. - Backpressure: queue work when remaining is low instead of continuing to fan out requests.
- Prefer fewer calls: reduce polling where you can; request only what you need; cache responses when it’s safe for your workflow.
- Make retries safe: only retry requests when you can tolerate duplicates, or when your integration can de-duplicate on its side.
- Log
X-RateLimit-Limit,X-RateLimit-Remaining, andX-RateLimit-Resetfor every response in production. - Alert when
X-RateLimit-Remainingstays low over sustained periods. - If you routinely hit 429s during normal volume, plan for a lower steady-state request rate or an Enterprise limit tier.