Rate Limits
API rate limits and how to handle them
The Micro API enforces rate limits per API key to ensure availability for all users.
Limits
Section titled “Limits”| Limit | Value |
|---|---|
| Requests per second | 10 |
| Burst | 2 |
| Requests per day | 100,000 |
Requests are metered per API key. The burst allowance is small, so a parallel fan-out of more than a couple of simultaneous requests can return 429 even when your average rate is well under 10/second — spread concurrent work out rather than issuing it all at once.
:::note These limits apply during the beta period and may change. Contact support if you need higher limits for a specific use case. :::
Handling 429s
Section titled “Handling 429s”When you exceed the limit, the API returns 429 Too Many Requests. Throttling happens at the gateway, so the body is a bare { "message": "Too Many Requests" } rather than the usual error envelope.
No Retry-After header is sent, so back off on your own schedule. Exponential backoff with jitter is the safe default — jitter matters because it stops several retrying clients from resynchronising into the same burst.
async function queryWithRetry(teamId: string, body: object, retries = 3) { for (let attempt = 0; ; attempt++) { const res = await fetch(`https://developers.micro.so/v2/prism/${teamId}/contact/query`, { method: 'POST', headers: { 'x-api-key': apiKey, 'Content-Type': 'application/json' }, body: JSON.stringify(body), });
if (res.status !== 429 || attempt >= retries) return res;
const backoff = 2 ** attempt * 500 + Math.random() * 250; await new Promise((r) => setTimeout(r, backoff)); }}The official SDKs already retry 429 and 5xx with backoff; set maxRetries on the client to tune it.