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 your access token.
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 periodic syncs (for example, checking the status of all your active
shipments), 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? Have your service provider 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.