Skip to main content
MADIAD Hub applies a per-customer request rate limit. Publishing is unlimited on every paid plan, so for a publish call this rate limit is the only thing you can hit:
  • Rate limit — how fast you can call the API, checked on every authenticated request.
  • Metered allowances — FFmpeg minutes, profiles, and daily DMs are still capped by plan; posts are not. See Usage for your current figures.
The two are independent — you can have your entire FFmpeg allowance left and still get rate-limited by bursting too many requests too quickly.

​
The limit

  • Fixed 60-second window, tracked per customer account (not per API key or per profile).
  • Default: 120 requests/minute. Higher limits are available for high-volume integrations — contact support if you need a higher ceiling.
  • It’s a fixed window: the counter resets on each 60-second boundary, so usage doesn’t carry over to the next window.

​
When you exceed it

The API returns:
See Errors for the full error code reference.

​
Handling 429s

  • Respect Retry-After. The header tells you exactly how long to wait (in seconds) before your next attempt — don’t retry sooner.
  • Back off exponentially on repeated 429s if you’re calling in a loop or from a queue worker, rather than hammering the endpoint every time the window resets.
  • Spread out bursts. If you’re fanning out many posts at once (e.g. bulk scheduling from a script), add a small delay between requests instead of firing them all concurrently.
If a request that creates something (like a post) gets rate-limited and you retry it, send the same Idempotency-Key you used on the first attempt — see Idempotency. That way a retry can never create a duplicate.

​
If the limiter itself has a problem

The rate limiter fails open: if the underlying check errors out for any reason, MADIAD Hub lets the request through rather than blocking it. A limiter outage on our side will never be the reason your legitimate traffic gets blocked.