At a glance. As a guideline, unauthenticated requests are currently limited to around 30 requests per minute, and authenticated requests to around 120 requests per minute. Limits are counted per IP address and user combined, over a sliding window. These values are indicative and may change. See Adaptive and burst protection.
Why rate limits exist
Share Of Model takes the security of its services and of your data very seriously. Rate limits are one of several layers of protection. They are not there to slow down legitimate integrations. They keep the platform reliable, fair and secure for every customer.Service stability
Capping request bursts protects the infrastructure behind the APIs from sudden spikes, so response times stay predictable for everyone, including during peak hours.
Data protection
Limits make large-scale scraping, credential stuffing and brute-force attempts impractical, which helps protect your brand data, your analyses and your account.
Fair usage
Shared capacity is spread evenly, so a single runaway script or misconfigured agent cannot degrade the experience of other users and organisations.
Abuse prevention
Unauthenticated traffic gets a lower limit, which reduces the attack surface of public endpoints such as token exchange.
Limits
- Unauthenticated
- Authenticated
- MCP server
A request is unauthenticated when it carries no valid token, for example when you exchange an API key for a JWT. These requests are subject to the lower limit of around 30 requests per minute.
Adaptive and burst protection
The per-minute values above are not the only safeguard. The platform also applies burst protection that limits how many requests can arrive within a very short period, even when the per-minute limit has not been reached. The thresholds for burst protection are not published.How limits are counted
Limits are tracked per combination of IP address and user. Each pair of client IP address and authenticated identity has its own counter. The counter uses a sliding window: at any moment, the platform looks at the requests you sent during the preceding minute. There is no fixed reset time. Capacity frees up gradually as your older requests move out of the window. What this means in practice:Two users behind the same IP address
Two users behind the same IP address
Each user has their own quota. Colleagues who share an office network or a VPN exit node do not use up each other’s requests.
One user on several IP addresses
One user on several IP addresses
Each IP address counts separately for the same user. For example, a laptop and a server both using the same account are tracked separately.
API calls and MCP calls from the same user
API calls and MCP calls from the same user
The same limits apply to the APIs and the MCP server. Plan for both when you run scripts and agents on the same account.
Core API and Search API
Core API and Search API
Both surfaces are subject to the limits described on this page. Treat them as one budget when you design high-volume jobs.
When you exceed the limit
Requests sent after a limit is reached are rejected with HTTP429 Too Many Requests. Because the window slides, requests are accepted again as your earlier requests move out of the last minute. Your data, analyses and tokens are not affected. The rejected request is simply not processed, and you can send it again after waiting.
Handle rate limiting in your code
Follow these steps to build an integration that stays within the limits and recovers cleanly when it does not.1
Reuse your access token
Exchange your API key once and keep the JWT in memory until it expires. This keeps you well below the unauthenticated limit.
2
Pace your requests
Spread calls evenly over time rather than sending them in bursts. Aim to stay well below the published per-minute values, since burst protection can reject a quick series of requests on its own.
3
Retry with exponential backoff
When a request is rejected for rate limiting, wait before retrying, and double the wait on each consecutive failure. If the response includes a
Retry-After header, use its value instead.4
Cap the number of retries
Give up after a few attempts and log the failure, so a persistent problem surfaces instead of looping forever.
429 Too Many Requests and honour the Retry-After header when it is present.
Best practices
Cache responses
Metrics are produced per collect, so the data behind a finished collect does not change between calls. Store results locally instead of calling the same endpoint repeatedly.
Request only what you need
Pass several IDs in
collect_ids to get aggregated metrics in one call, rather than requesting each collect separately and combining the results yourself.Run jobs sequentially
Avoid firing dozens of parallel requests from the same account and IP address. A small worker pool with pacing is faster overall than a burst that gets rejected.
Keep agents focused
With the MCP server, specific questions scoped to one brand, analysis or period need fewer tool calls than broad, open-ended ones.
An integration that reuses its token, paces its calls, keeps a margin below the published values and backs off on rejection is much less likely to be limited.
Related pages
Authentication
Get and refresh a Bearer JWT.
MCP Integration
Connect an LLM agent to your data.
API keys
Create, scope and rotate API keys.