Rate Limits
What the Flow Myna API allows, and what happens when you go over.
Current Limits
| Limit Type | Value | Notes |
|---|---|---|
| Batch Size | 100 events/objects | Per batch request |
| Objects per Event | 1-50 objects | Single and batch event endpoints. Larger events are rejected with 422 |
| Request Rate | 1,200 requests/minute | Per API key. A batch counts as one request |
| Event Name Length | 1-200 characters | Validated on every request |
| Object Type Length | 1-100 characters | Validated on every request |
| Object ID Length | 1-500 characters | Validated on every request |
Batching keeps you well under the limit. The rate limit counts requests, not events, so 1,200 batches a minute is up to 120,000 events a minute on a single key. If you're planning to send more than that, contact us first so we can make sure it lands cleanly.
Going Over the Limit
Past 1,200 requests in a rolling minute, that key gets 429 Too Many Requests until the oldest requests in the window age out. Other keys in your workspace are unaffected — the budget is per key, so one noisy integration can't throttle the rest.
Retry-After: 43
Seconds until this key has budget again. Sent on every 429.
The response body says the same thing in words:
Retry-After is the only header we send. There are no X-RateLimit-* headers — read Retry-After on the 429 rather than tracking a budget yourself.
Handling Rate Limits
If you're rate limited (429 status), implement exponential backoff:
- 1. Read the
Retry-Afterheader - 2. Wait that many seconds before retrying
- 3. If it's missing, back off: 1s, 2s, 4s, 8s...
- 4. Add jitter so retries don't all land together
Our SDKs handle this automatically. The Python and Node.js SDKs include built-in rate limit handling with intelligent backoff.
Need Higher Limits?
If your integration requires higher rate limits:
- Contact us — We can discuss enterprise options
- Use batching — Send up to 100 events per request
- Optimize timing — Spread requests over time