Evidence review
Before you buy intake software that plugs into your matter system, somebody should read the developer documentation. The published limits decide how the integration behaves on your busiest morning, and they are usually the last thing anyone mentions.
When a firm buys intake software that connects to its practice management system, the sales conversation covers features, seats and price. It rarely covers the one constraint that decides how the connection behaves when the firm is busy: how many requests the platform will accept, and who that allowance belongs to.
Those numbers are published. They sit in developer documentation that firms have no reason to read, and they are worth reading, because two integrations that look identical in a demonstration can behave very differently once they are carrying your Monday morning.
Below is what one platform publishes. We use Clio for the worked example because Clio documents this openly, which is to its credit; a vendor that publishes nothing is harder to check, and that absence is its own answer.
Clio's developer documentation describes two separate platforms. The Clio Manage API is the older of the two. The Clio Platform, which covers Grow, is the newer one. They have different limits, and the difference is the part worth understanding.
Clio Manage. The documentation states that "Requests to API v4 are rate-limited by access token," with a default of 50 requests per minute during peak hours. Every response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers, so an integration can see how much room it has left. If the limit is exceeded, a Retry-After header is supplied in the 429 response indicating the number of seconds to wait. Peak hours for the United States and Canada are 04:00 to 19:00 Pacific, Monday to Friday, and the documentation says limits are increased outside them, without saying by how much.
Clio Platform, covering Grow. The documentation states that "All applications are assigned a default rate limit of 3 requests per second," and that "Rate limits are applied per OAuth application. This means the total number of requests made by your application across all users is subject to a shared limit." It adds that each request counts toward the quota "regardless of which user's access token is used." Limits are enforced separately per region.
Both pages carry the same sentence about increases: "We do not support custom rate limit increases for applications at this time."
Read those two rules next to each other and the important distinction is not the size of the allowance. It is who owns it.
A limit applied per access token belongs to your firm. Your allowance is yours, and how heavily another firm uses the same software has nothing to do with it. Growth in the number of customers a vendor has does not take anything away from you.
A limit applied per OAuth application belongs to the vendor, and every firm using that product draws from the same pot. The vendor's busiest customer and your firm are spending the same allowance. A product that felt quick during a pilot with thirty firms on it is doing the same work through the same opening when it has three hundred, and the platform says the ceiling cannot be raised.
That is not a reason to avoid such a product. Plenty of well-built integrations sit comfortably inside three requests per second, because they move a handful of records when something actually happens. It is a reason to ask how the product is built, and to be suspicious of any design that polls constantly or re-reads large lists on a schedule, because those patterns consume a shared allowance whether or not anything changed.
A firm signs up eleven new prospective clients before lunch after a marketing push. Each one triggers an intake form, a conflict check lookup, a contact write, a matter creation and a handful of field updates.
Under a per-token limit, that work is yours to spend and the headers tell the software how much room is left, so a competent integration paces itself and finishes.
Under a shared per-application limit, your eleven arrive alongside everyone else's. The integration gets a 429, and what happens next depends entirely on how the vendor wrote it. Good behaviour is to wait and retry without losing anything. The failure worth asking about is the one where a record is written twice, or half-written, because a retry was not designed carefully.
That is the question underneath all of this: what happens to a record when a write fails halfway. Rate limits are simply the most common way to find out.
Five questions. Put them to the vendor's support or solutions engineer, who will know the answers.
Which API does your integration use, and is its rate limit per user or per application? A vendor who knows this answers immediately. One who has to find out has never hit the limit, which may be reassuring or may mean nobody has tested it.
What does your software do when it receives a 429? You want to hear that it waits for the interval the platform specifies and retries. You do not want to hear that it skips the record, or that the user is asked to try again.
If a write is interrupted, can the same record be created twice? Ask what stops it. An answer that describes checking for an existing record before writing is a good sign.
Does the integration poll on a timer, or does it act when something happens? Polling on a short timer spends a shared allowance continuously.
Do you run batch work outside peak hours? Anyone who has read the same documentation knows peak hours exist and what they are.
None of these requires you to be technical. They require the vendor to have thought about the days when things do not go smoothly.
We build integrations, so these limits constrain us in exactly the same way. We cannot buy our way past three requests per second any more than a packaged vendor can, and any claim to the contrary from anyone should be treated as a sales line. The documentation says custom increases are not available, and that applies to everybody.
What a custom build can do is decide what the software attempts. A system built for one firm can be designed to write when something happens, to check before it creates, and to do bulk work at night. That is a design decision rather than a capability, and a packaged product that has already made those decisions well is a fine answer.
If you are still working out which system should own which record, the guide to law firm CRM, legal intake software and practice management covers that boundary first, and it is the better place to start. If you know the boundary and want to find where your own handoffs break, the intake workflow scorecard is the worksheet.
Sources. Clio developer documentation, Clio Manage API rate limits and Clio Platform API rate limits, both read on 19 September 2026. Quotations are from those two pages. Limits and peak-hour windows change; check the current pages before relying on any figure here. Goodstack has no partnership or affiliation with Clio, and nothing here is endorsed by them.