Miro rate limits are credit based: weight your calls, not your request count

Miro rate limits are credit based: weight your calls, not your request count

TL;DR

Context: Miro rate limiting: 100,000 credits per minute, per-method weights, X-RateLimit headers Miro rate limits are credit based: a global limit of 100,000 credits per minute, evaluated per method, with per-method weights so cheap reads cost fewer credits than heavy writes. Over the limit you get 429 with code tooManyRequests and message Request rate limit exceeded. Every API response carries X-RateLimit-Limit (total credits per minute), X-RateLimit-Remaining (credits left in the window), and X-RateLimit-Reset (UNIX timestamp when credits reset).

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Miro rate limits are credits, not request counts Miro gives your app 100,000 credits per minute, and requests are not all equal: each API method is evaluated per method with its own weight, so a heavy write burns more credits than a cheap read. The gotcha is counting requests. If you budget 100,000 requests per minute you will blow past the limit long before that, because the expensive calls eat credits faster than your counter thinks. When you exceed it: - 429 Too many requests - code: tooManyRequests, message: Request rate limit exceeded What to do with the headers, which ride on every response: - X-RateLimit-Limit: credits allocated per minute - X-RateLimit-Remaining: credits left right now - X-RateLimit-Reset: UNIX timestamp when the window resets Practical pattern: read X-RateLimit-Remaining on every response and throttle yourself before you hit zero, instead of discovering the limit via 429s. And when you do get a 429, back off exponentially: retrying at full speed just re-triggers the limiter. Batching multiple operations into one call is the cheapest way to stay under the budget.

Context: Miro rate limiting: 100,000 credits per minute, per-method weights, X-RateLimit headers Miro rate limits are credit based: a global limit of 100,000 credits per minute, evaluated per method, with per-method weights so cheap reads cost fewer credits than heavy writes. Over the limit you get 429 with code tooManyRequests and message Request rate limit exceeded. Every API response carries X-RateLimit-Limit (total credits per minute), X-RateLimit-Remaining (credits left in the window), and X-RateLimit-Reset (UNIX timestamp when credits reset). The guide recommends exponential backoff on 429, watching the headers in real time, and batching operations to spend fewer credits.

Source: Miro rate limiting: 100,000 credits per minute, per-method weights, X-RateLimit headers Miro rate limits are credit based: a global limit of 100,000 credits per minute, evaluated per method, with per-method weights so cheap reads cost fewer credits than heavy writes. Over the limit you get 429 with code tooManyRequests and message Request rate limit exceeded. Every API response carries X-RateLimit-Limit (total credits per minute), X-RateLimit-Remaining (credits left in the window), and X-RateLimit-Reset (UNIX timestamp when credits reset). The guide recommends exponential backoff on 429, watching the headers in real time, and batching operations to spend fewer credits.

Verified resolution: # Miro rate limits are credits, not request counts Miro gives your app 100,000 credits per minute, and requests are not all equal: each API method is evaluated per method with its own weight, so a heavy write burns more credits than a cheap read. The gotcha is counting requests. If you budget 100,000 requests per minute you will blow past the limit long before that, because the expensive calls eat credits faster than your counter thinks. When you exceed it: - 429 Too many requests - code: tooManyRequests, message: Request rate limit exceeded What to do with the headers, which ride on every response: - X-RateLimit-Limit: credits allocated per minute - X-RateLimit-Remaining: credits left right now - X-RateLimit-Reset: UNIX timestamp when the window resets Practical pattern: read X-RateLimit-Remaining on every response and throttle yourself before you hit zero, instead of discovering the limit via 429s. And when you do get a 429, back off exponentially: retrying at full speed just re-triggers the limiter. Batching multiple operations into one call is the cheapest way to stay under the budget.

Source URL: http://developers.miro.com/reference/rate-limiting