Clio vs MyCase: What Each API Will and Won't Let You Build

Quick answer: Clio's API is the larger surface by a wide margin. Its Manage API documents 88 resource groups, including medical records, damages, docket rules, report schedules, document templates and webhooks, and any firm above the entry tier can create its own developer app the same day. MyCase's Open API is narrower, has no email resource, publishes no rate limit, and is only sold on the Advanced tier at $130 per user per month (raised from $109 in 2026), with credentials issued by support email. Either will run a Claude connector; the difference shows up when you build reporting, intake or document workflows on top. Which platforms gate API access, and at what price: the lock-in comparison.

---

In August we set up a solo attorney on Clio over a screen share. Everything ran by the end of the call, and then he asked three things: what we do, what the connector does today, and what was possible that we hadn't built yet. We answered the third one badly. We said cross-matter reporting and scheduled runs weren't possible, and they are; Clio has reports, report_presets and report_schedules in its API, we just hadn't written anything against them. Since then the rule is "not built" when that's the truth, and "not possible" only for what a vendor genuinely doesn't expose, because a litigator will check.

What does Clio's API cover that MyCase's doesn't?

Clio's Manage API documents 88 resource groups. Our connector reads and writes 10 of them: matters, contacts, documents, tasks, calendars, activities, bills, notes, users, plus our own audit export. When we went through the other 78 after that call, the ones with commercial weight fell into a few piles.

Personal injury is modelled inside Clio itself. medical_records, medical_records_details, medical_bills, damages and matter_protected_funds are first-class resources. A PI firm that wants Claude to total the specials on a file, or flag a lien that isn't in the protected-funds ledger, doesn't need a spreadsheet next to Clio; the structure already exists and the API returns it.

The deadline engine is exposed too: jurisdictions_to_triggers, matter_dockets, service_types and reminders. That's what turns "what's due" from a question into a rule set, and it's where a statute sweep across every open matter gets built.

Then the pieces that let an integration run on its own instead of when asked. Clio has webhooks and report_schedules. The webhook catalogue covers activity, bill, calendar_entry, communication, contact, matter and task, and every subscription expires, three days by default and 31 at most, so anything built on them needs a renewal job or it goes quiet without an error. There's no document event. A new document is usually the result of a matter changing stage, so you subscribe to matter updates or you poll, which we covered in the no-document-webhook post.

Realization data (billable_matters, outstanding_client_balances, allocations, line_items), matter_stages for phase tracking, task_templates so a new matter builds its own task list, and document_automations with document_templates for generating a demand letter from the matter file round out the list. Intake lives in a separate product, Clio Grow, with its own inbox_leads and sources; that's a second API and a second access request.

Custom fields are readable and writable through custom_field_values, with a trap on the write side we covered in the value-instance-id post. Document upload is a documented three-step: register the document, PUT the bytes to the returned S3 URL, then PATCH it as fully uploaded; skip the third step and the file appears in Clio without content. And the whole API is served from four regions, au, ca, eu and us, fixed when the account is created, so an integration has to call the matching host or the OAuth handshake goes nowhere.

What does MyCase's API cover that Clio's doesn't?

Less, and it's worth being plain about that. The one thing MyCase does better structurally is that leads sit inside the same API as cases. MyCase's published integration surface includes leads, referral sources, call logs, custom fields, notes, events, expenses, locations, practice areas and case stages, plus creation and update on cases, companies and people. An intake-to-case flow on MyCase is one credential and one host, external-integrations.mycase.com, where Clio splits it across Manage and Grow.

The gaps are the kind nobody publishes. There's no email resource at all, which we found out when a MyCase firm asked us for six write paths and the sixth was "push this email into the matter"; five were feasible and that one wasn't. Event creation isn't documented, only update. MyCase doesn't publish a rate limit. We haven't found a webhook catalogue comparable to Clio's seven events, so on MyCase we design for polling and treat anything event-driven as an optimisation. Document write-back is narrower than Clio's, and that's one to confirm against your own account before promising anyone a closed loop.

Pagination is the one that bit a real firm. MyCase returns the next page as a Link header with rel="next", the RFC 5988 style, rather than a field in the response body. Our list-tasks tool read page one and stopped. A firm reported it from a live docket on 21 July; the fix that follows the cursors to the last page shipped in connector 1.2.0 on 26 July with 92 tests passing. The same undercount showed up on Clio three days later, from a firm running our connector across several hundred matters. On either API, a list that fits on one page in testing will silently be a fraction of the book in production.

How do the rate limits change a batch job?

Clio's Manage API allows 50 requests per minute per access token during peak hours, and peak hours are the working day: 04:00 to 19:00 Pacific, Monday to Friday, for US and Canadian accounts, 07:00 to 22:00 GMT for the EU, 06:00 to 21:00 AET for Australia. Off-peak the limit rises. Every response carries X-RateLimit-Limit, -Remaining and -Reset, a 429 carries Retry-After, and pages cap at 200 records.

Clio's newer Platform API runs at 3 requests per second, counted per application across every user of that application. Clio's own wording is that "the total number of requests made by your application across all users is subject to a shared limit", and both rate-limit pages say "We do not support custom rate limit increases for applications at this time." The fifth attorney and the fifteenth draw on the same pipe, and no tier widens it.

Do the arithmetic on a normal job. Normalising one custom field across 3,000 matters is a read and a write per matter, 6,000 calls. At 50 a minute during the day that's two hours if nothing else touches the token. A firm-wide report over every open matter can refresh a handful of times a day rather than every few minutes. That's why every batch we build is resumable, previews its changes before writing, and can roll back per matter; the batch design post has the mechanics.

MyCase publishes no number. Our connector caps itself at 30 requests a minute, honours Retry-After when a 429 comes back, and gives up after five retries rather than hammering. An unpublished limit is harder to plan around than a low published one, because the only way to learn it is to hit it on live client data.

Who is allowed to call the API at all?

On MyCase the Open API is a feature of the Advanced tier, $130 per user per month on annual billing as of August 2026 (it was $109 until the 2026 increase). Basic is $50 and Pro is $89, and neither includes it, so a ten-person firm on Pro is looking at $2,400 a year more before a single call is made. MyCase's documentation also says it doesn't provide implementation support and points firms to a Certified Consultant; we went through what that means in practice in the Open API integration post.

Credentials come from MyCase support, by email. You send the OAuth redirect URI, the scope you need and the email of the firm's MyCase admin, and you wait; our own request took 13 business days. The redirect URI is where installs nearly die. Our connector listens on 127.0.0.1:5678 by default and MyCase commonly registers 5680. On one install this summer, for a four-attorney New York firm, the attorney had sent MyCase the port off our website, we'd pasted a config with the other one, and MyCase's reply came back with "something like" ours. If the two ports differ, the browser approves the login and then lands on nothing. Since then we forward MyCase's reply before anyone pastes a config, and set MYCASE_REDIRECT_PORT to whatever they actually registered. Access tokens last 24 hours, refresh tokens about two weeks, then it's a fresh login.

Clio is self-service. Any user with permission creates a developer app at developers.clio.com, sets the redirect URI to exactly http://127.0.0.1:5678/callback, and has a client ID and secret the same day. The gates are elsewhere. The entry tier, EasyStart, doesn't include API access. The app has to point at the firm's region, and for months our connector recognised only us and eu; an Australian firm setting au was silently sent to the US host. The current build accepts all four and refuses to start on anything else.

What do our connectors expose today, and what do the APIs allow?

Four labels in this table. Built means the tool exists in the connector today. Not built means the API supports it and we haven't written the tool. Not possible means the vendor doesn't expose it. Unverified means we haven't found it documented and haven't tested it against a live account.

Most of the Clio connector column says not built, and that's an offer rather than a wall: the API is there and the connector work is days per resource. The only two cells in the whole table that say not possible are both on MyCase, both on email.

What does this mean for three kinds of builds?

Reporting. Clio has the raw material for realization and pipeline reporting in the API, and a schedule resource to run it without a person clicking. The constraint is the 50 a minute and the shared Platform cap, which set how fresh a firm-wide number can be. On MyCase the reporting data is there for cases, time and billing, and the discipline is pagination: follow the Link header to the end or the totals are wrong and nothing tells you.

Intake automation. MyCase is the simpler build because leads, referral sources and cases share one credential. On Clio the lead lives in Grow, which is a separate developer application and access request; we submitted ours on 2 July and are still waiting on it. What Clio gives you in exchange is contact and matter webhooks, so the moment a lead converts something can run, provided the renewal job keeps the subscription alive.

Document workflows. On Clio the loop closes: read the matter, draft with the model, register the document, upload the bytes, mark it uploaded, and it appears on the matter with nobody downloading anything. Document templates and automations sit in the API as well, unbuilt in our connector. There's still no document event, so "when a document appears" has to become "when the matter changes stage", or a poll. On MyCase the drafting side is identical and the upload side is where you check your own account before you promise a closed loop.

So the verdict from having built both. For reporting or documents, Clio's API gives you far more to stand on and a rate limit you can plan around. For intake at a firm already on MyCase Advanced, MyCase is the shorter path, with the email gap and the unpublished rate limit written into the plan. Whichever it is, the connector you install today is the smaller of the two numbers in that table and the API is the larger one; ask any vendor, us included, which of the two they're describing.

Frequently asked questions