Skip to main content
Share Of Model limits how many requests a client can send within a sliding time window. These rate limits apply to every public surface: the Core API, the Search API and the MCP server.
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

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.
Tokens can be reused until they expire. Exchange your API key once, cache the JWT, and refresh it only when you receive a 401. Requesting a new token before every call wastes your unauthenticated quota.

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.
All the limits described on this page are indicative and subject to change at any time, without notice. Share Of Model continuously adjusts its protections based on security signals, traffic patterns and suspected abuse. A client may therefore be limited sooner than the published values suggest, temporarily or permanently.
Do not design your integration to use the full published quota. Keep a comfortable margin below it, and always handle rejected requests gracefully, as described in Handle rate limiting in your code.

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:
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.
Each IP address counts separately for the same user. For example, a laptop and a server both using the same account are tracked separately.
The same limits apply to the APIs and the MCP server. Plan for both when you run scripts and agents on the same account.
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 HTTP 429 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.
Retrying immediately in a tight loop does not help. Every retry counts against your quota and keeps you over the limit for longer. Always wait before retrying.

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.
The examples below apply these steps. They retry on HTTP 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.

Authentication

Get and refresh a Bearer JWT.

MCP Integration

Connect an LLM agent to your data.

API keys

Create, scope and rotate API keys.