Mosaic enforces API rate limits to ensure platform stability, protect against abuse, and maintain fair usage across customers. Rate limiting is applied at multiple layers depending on the API and traffic pattern. If a rate limit is exceeded, Mosaic returns an HTTP 429 Too Many Requests response. These limits apply to all requests that reach Mosaic APIs, including calls made through Mosaic SDKs and other client-side integrations.
Mosaic applies rate limiting at two layers: edge rate limiting at the network level and application-level rate limiting on selected APIs.
Your effective limit is always the most restrictive limit reached at either layer. Edge (Cloudflare) rate limits apply to all Mosaic APIs, while application-level limits apply only to the APIs explicitly listed below.
All Mosaic APIs are protected at the network edge using Cloudflare.
| Property | Details |
|---|---|
| Limit | 90,000 requests per minute |
| Scope | Per source IP address |
| Applies to | All Mosaic APIs |
This layer protects the platform from traffic spikes, abuse, and denial-of-service patterns before requests reach Mosaic services.
If your traffic originates from a shared NAT, proxy, or gateway, multiple clients may appear as a single IP address and may reach the edge limit sooner.
Application-level rate limiting is not platform-wide. It is enforced on selected high-volume operational APIs in addition to the edge protections described above.
Fraud Prevention enforces application-level rate limiting for high-volume operational usage.
| Property | Details |
|---|---|
| Limit | 10,000 requests per minute |
| Scope | Per tenant / account |
Identity Management enforces applicative throttling to protect backend services.
| Property | Details |
|---|---|
| Limit | 20,000 requests per minute |
| Scope | Per application and/or per client IP address |
Journeys enforces per-user throttling to prevent abuse of user-driven flows. This protection is designed to mitigate brute-force attempts and excessive invocation of user-level flows.
| Property | Details |
|---|---|
| Limit | 10 requests per second |
| Scope | Per user |
At this time, Identity Verification does not enforce dedicated application-level rate limiting. All Identity Verification APIs remain protected by the platform-wide edge rate limiting described above.
When a rate limit is exceeded, Mosaic returns:
- HTTP Status:
429 Too Many Requests
Clients should treat 429 responses as temporary and retry after an appropriate delay.
To ensure resilient integrations, Mosaic recommends:
- Use exponential backoff with jitter—when retrying after a
429response, wait progressively longer between attempts and add a small random delay to avoid multiple clients retrying at the same moment. - Avoid tight retry loops—don't retry requests in rapid succession without a delay, as this can worsen rate limiting and resemble abusive traffic.
- Spread out batch operations—if you run bulk jobs such as user migrations or batch updates, distribute requests over time rather than sending them all at once.
- Prevent synchronized spikes—avoid designs where many clients or services send requests at the same scheduled instant (for example, all on the minute mark).
If you expect sustained traffic above the default limits (for example, migrations, bulk operations, or high-volume production launches), contact Mosaic.