Rate Limits
To protect service stability for all users, the API applies a request limit per minute per token.
Default limit
60 requests per minute, per access token. The limit is counted independently per token — if you have several tokens (for example, one for reading and one for writing), each has its own quota.
Rate limit headers
Responses processed by the rate limiter include these headers so you can monitor your usage:
| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum number of requests allowed in the current window. |
X-RateLimit-Remaining | How many requests you have left in the current window. |
X-RateLimit-Reset | Unix timestamp of when the current window resets. |
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 57
X-RateLimit-Reset: 1788806540
If you're consuming the API from JavaScript in the browser (not server-to-server), you need to read
these headers via response.headers.get('X-RateLimit-Remaining') — due to CORS, the browser hides
any header that isn't "safelisted" unless the server explicitly lists it in
Access-Control-Expose-Headers, which already includes these.
What happens if you exceed the limit
You get 429 Too Many Requests:
{ "message": "Too Many Requests." }
along with a Retry-After header telling you how many seconds to wait before retrying:
Retry-After: 42
If your integration does bulk syncs (for example, paginating through every lead), the simplest
approach is to read X-RateLimit-Remaining and pause as it approaches 0, or just retry with
backoff when you get a 429, respecting the Retry-After value.
Need a higher limit for your use case? Reach out at midlaplatform.com.
The default is 60 requests per minute; the deployment may configure a different value.
Use X-RateLimit-Limit as the actual limit. Quotas are independent per token, organization
and API audience. Multiple tokens of one Platform integration do not share a quota.