Cloud API entity read rate limits
Caseware introduced a dedicated rate limit for Cloud API entity reads at the end of August 2026. The limit applies to /entities and its subresources in API v1 and v2.
The limit protects service performance for firms that share the same infrastructure.
Some integrations began receiving HTTP 429 Too Many Requests status codes after the change. The change was not communicated before release.
Current entity read limit
Entity reads use a per-user budget that is separate from other GET requests.
The token bucket:
-
Holds 60 tokens.
-
Replenishes 10 tokens per second.
-
Uses 60 tokens for each entity read.
As a result, space consecutive entity reads at least six seconds apart.
The limit applies to /entities and its subresources in /api/v1 and /api/v2.
Other endpoints, including /engagements, use a separate, larger budget.
Handle HTTP 429 status codes
If two entity reads occur too close together, the second request can return an HTTP 429 Too Many Requests status code.
For example, requesting page 1 and then immediately requesting page 2 can produce a successful first response and a 429 status code for the second request.
The page number, pageSize and underlying data do not affect the limit. The spacing between entity reads determines whether the request exceeds the limit.
Rejected requests can return within tens of milliseconds. The response has an empty body and no Retry-After header because the API gateway rejects the request before it reaches the entities service.
Adapt an integration to the current limit
To work with the current entity read limit:
-
Space consecutive entity reads at least six seconds apart and stay within 10 entity reads per minute per user.
-
Treat an HTTP 429 Too Many Requests status code as retryable.
-
Wait about six seconds before retrying a rejected request.
-
Increase the delay exponentially if subsequent requests are also rejected.
-
Use
X-RateLimit-Remaining,X-RateLimit-Burst-Capacity,X-RateLimit-Replenish-RateandX-RateLimit-Requested-Tokensto pace requests. -
Use targeted search or filter queries instead of retrieving every page.
Planned changes
Caseware is reviewing a dedicated entity read limiter for normal paginated lookups.
The proposed limit allows a three-page burst at up to 20 requests per minute. It is expected in an upcoming release.
Until the change is released, build integrations against the current limit. Existing pacing and retry logic will continue to work after the change.
Frequently asked questions
My integration did not change. Why did it start receiving 429 errors around September 1?
Caseware added a dedicated rate limit for Cloud API entity reads at the end of August 2026.
Before the change, entity reads were effectively not throttled. Requests made in quick succession can now exceed the limit.
For example, requesting page 1 and then immediately requesting page 2 can cause the second request to be rejected.
Why is this limit required?
Entity reads are among the most expensive queries served by the API.
Sustained retrieval of large volumes of entity data caused service degradation for other firms using the same infrastructure. The limit protects service performance for all customers.
What is the entity read limit?
Entity reads use a per-user token bucket that is separate from other GET requests.
The bucket holds 60 tokens and replenishes 10 tokens per second. Each entity read uses 60 tokens.
In practice, space entity reads about six seconds apart.
The limit applies to /entities and its subresources in /api/v1 and /api/v2.
Which requests are affected?
The limit applies to /entities and its subresources.
It does not apply to /engagements or other endpoints, which use a separate, larger budget.
The page number, pageSize and underlying data do not affect the limit. Only the spacing between entity reads affects it.
Why does a 429 response have no Retry-After header or response body?
The API gateway rate limiter generates the 429 status code before the request reaches the entities service.
The response therefore returns quickly with an empty body. A Retry-After header is not currently included.
Wait about six seconds before retrying the request.
How should I update my integration?
Make the following changes:
-
Space consecutive entity reads at least six seconds apart and stay within 10 entity reads per minute per user.
-
Treat an HTTP 429 Too Many Requests status code as retryable.
-
Wait about six seconds before retrying and increase the delay exponentially after repeated rejections.
-
Use
X-RateLimit-Remaining,X-RateLimit-Burst-Capacity,X-RateLimit-Replenish-RateandX-RateLimit-Requested-Tokensto pace requests. -
Use targeted search or filter queries instead of retrieving every page.
An integration that does not retry a rejected request can omit the rejected page from its results.
Should I retry as quickly as possible until the request succeeds?
No. Wait before retrying a rejected request.
Rapid repeated requests add load and can put access at risk. Use the pacing and retry guidance described above.
Will the entity read limit change?
Yes. Caseware is reviewing a dedicated entity read limiter that allows a three-page burst at up to 20 requests per minute.
The change is expected in an upcoming release. Continue to follow the current limit until the change is released.
Pacing and retry logic implemented for the current limit will continue to work after the change.
Can I use the entity APIs to export all of my firm's data?
No. The planned adjustment supports normal interactive use and small paginated lookups.
It is not intended for repeated retrieval of an entire firm's dataset.
For bulk export, synchronization or bulk operations, submit a feature request for a purpose-built capability.
How can I determine whether my integration is affected?
Check for HTTP 429 Too Many Requests status codes on /entities requests.
These responses can occur on the second or later request in a sequence and can return much faster than normal requests.
Log complete response headers and non-2xx response bodies to make diagnosis easier.