Most "Clio vs MyCase" articles compare billing screens and mobile apps. That's the wrong lens once you want AI in the loop. When the goal is automation, where Claude reads a matter, drafts something, and writes the result back, the comparison that matters is the API. What can it read, what can it write, how often can you call it, and what happens at the edges.
We learned this by building and shipping MCP (Model Context Protocol) connectors for both platforms: the open-source Clio MCP connector and a MyCase MCP connector. An MCP connector is the layer that lets Claude call a system's API directly, so the model isn't just talking about your matters, it's acting on them. Building both meant hitting the real limits of each platform, not the limits the marketing pages imply.
This is a diagnostic, not a verdict. There is no universally "better" platform for AI. There's the platform that supports the specific write-back your workflow needs, and the platform you already pay for. Usually you should automate the one you're standardized on rather than migrate a whole firm to chase an API feature. The point of this post is to tell you, before you commit a dev budget, which questions actually decide the build.
The Only Question That Matters: Read vs Write
Reading from a legal practice management tool is easy. Almost any API gives you matters, contacts, and document metadata. That's enough to ask Claude "summarize this matter" or "what's on my calendar." It feels like magic for about a week.
The value is in writing back. Drafting a consult memo and uploading it into the right matter. Normalizing a messy address field across hundreds of matters. Logging a time entry from a transcript. The moment your automation has to write, you find out how deep the platform's API really goes, and that's where Clio and MyCase diverge.
Clio vs MyCase for AI automation: what we found building connectors for both
| Capability | Clio Manage API | MyCase API |
|---|---|---|
| Custom field read + write | Yes, via PATCH matter (with the value-id trap below) | More limited in practice; verify per account before promising it |
| Document upload (write-back) | Yes, documented two-step presigned-S3 PUT | Narrower; confirm the upload path you need exists |
| Webhook coverage | 7 event types, no document event; expire in 3 to 31 days | Fewer public events; lean on polling |
| Auth | OAuth 2.0; honor X-RateLimit headers | OAuth 2.0 |
| Canadian data region | Yes (ca.app.clio.com, PIPEDA) | Confirm with vendor for your jurisdiction |
A note on honesty before we go deeper: most published MyCase API documentation is thinner than Clio's, and access often depends on your plan and vendor approval. So treat the MyCase column as "verify before you promise it," not "it can't be done." We built the connector; the platform does real work. It just gives you less documented surface to plan against, which raises your discovery risk.
The Clio Custom-Field Trap That Eats a Day of Dev Time
If your firm leans on custom fields, this is the single most important thing to know before you scope a normalization or auto-fill project.
The Clio Manage API does support reading and writing custom fields. You read with GET matter?fields=custom_field_values{...} and write with a PATCH matter that carries a nested custom_field_values array. Here's the trap that costs people a day: the id inside that array is the value-instance id, not the field-definition id (custom_field:{id}). They look interchangeable. They are not. Send the field-definition id and the write either fails quietly or lands on the wrong target. You discover it only when you go check the data and it didn't change.
The second thing scoping people miss is field type. There's no hard limit on how many custom fields a matter can have, so a heavy custom-field setup is fine. But you can't normalize them blindly:
- Free-text normalizes cleanly. This is where Claude shines, messy entry in, your standard format out.
- Picklist only accepts predefined options (and option labels cap around 55 characters). You can't write an arbitrary normalized string into one.
- Currency rejects decimals in the way you'd expect, so naive money formatting breaks.
- Date needs a valid date, not a free-form string.
So "normalize all our custom fields" is never one job. It's: inventory the fields by type first, then apply the right rule per type. We document the value-instance gotcha in detail in the Clio custom-field API trap write-up. Honest disclosure: our open-source Clio MCP connector did not expose custom-field read or write out of the box, and had no generic update_matter tool. Custom-field support is real connector work, not a config flip. Anyone who tells you it works instantly hasn't built it.
Rate Limits Decide Your Batch Architecture
This is where teams that prototype against a single test matter get surprised in production. The Clio API wants you to throttle conservatively, around 3 requests per second per app. The docs also cite a 50-per-minute legacy figure. Honor the X-RateLimit-* headers, back off on a 429, and remember pagination caps at 200 records per page.
Do the math on a real job. Normalizing one field across a few thousand matters, with reads and writes, is not a loop you run over coffee. It's a long batch. That forces an architecture choice you should make on purpose:
- A resumable runner, so a 429 or a network blip doesn't make you start over.
- A dry-run preview, so the firm sees exactly what would change before a single write hits live client data.
- A per-matter rollback, because trust is the whole game when you're writing automatically into a system of record.
Tools like n8n are great for stitching a few API calls together, and we've seen firms reach for them first. But a no-code flow rarely handles backoff, resumption, and rollback well at this scale. That's the line where a quick automation becomes a real build. More detail in our Clio rate-limit and batch normalization guide.
There Is No "Document Created" Webhook (On Either Platform, Plan For It)
A common automation idea: "When Clio generates a document at a litigation stage, have Claude fill it in." Reasonable goal. The surprise is that Clio has no document webhook. The events it does emit are activity, bill, calendar_entry, communication, contact, matter, and task. No document.
So you react to the cause, not the effect. A document is usually generated because a matter changed stage, so you listen for the matter updated webhook (the stage change is the real trigger) or you poll. And whichever you choose, remember Clio webhooks expire, 3 days by default, 31 days maximum. If you don't renew them, your automation goes silent and nobody notices until a memo doesn't show up. We unpack this in the no-document-webhook post.
MyCase has the same shape of problem with fewer published events, so the practical answer on both platforms is the same: design for polling and treat webhooks as an optimization, not a foundation.
Closing the Loop: Document Upload Is the Part People Skip
Half-built legal automations get the AI to produce a beautiful draft and then make a human download it and upload it back by hand. That manual step quietly kills the whole value proposition.
Clio's document upload is a documented but non-obvious two-step presigned-S3 flow: you POST /documents to register it, PUT the file bytes to the returned put_url on S3, then PATCH the document as fully_uploaded. Miss the third step and the document looks uploaded but isn't. Once you've built it right, the loop closes: transcript and notes in, finished Word doc out, landed in the correct matter with no manual handoff. We walk through the exact sequence in the presigned-S3 upload guide.
MyCase document write-back is narrower, so this is exactly the kind of capability to confirm against your specific account before you promise a client a closed loop. The pattern is the lesson: read paths feel similar across platforms, write paths are where they differ.
Where Clio and MyCase Stop Mattering: The Model and Your Data
Two of the hardest questions in legal AI have nothing to do with which practice management tool you pick. They're about the model layer, and they apply equally to Clio and MyCase.
Zero Data Retention is on the API, not on chat
If a lawyer is uneasy about pasting client facts into a chat plan, that instinct is correct, and the fix isn't a bigger chat plan. Anthropic's Zero Data Retention (ZDR) is available on the API at the organization level, and a small firm can obtain it. It is not available on Claude Team chat. The API also doesn't train on your inputs by default. So the move is to run the confidential workflow through the Messages API under a ZDR arrangement rather than chasing retention guarantees inside a chat product that doesn't offer them. One caveat we learned: ZDR cleanly covers plain Messages-API calls, so keep the pipeline off surfaces like the Files API, Batch, and code execution where the guarantee gets murkier. See ZDR on Team vs API.
Canadian residency: Clio helps, the model is the residual
For a Canadian firm under PIPEDA, the practice-management data can stay in Canada because Clio offers a Canadian region (ca.app.clio.com). Your integration just has to call the Canadian base URL, easy to get wrong if you hardcode the US host. Zoom has a Canadian data center too, though its AI-content residency isn't guaranteed Canada-only, so the safe pattern is pull-and-store-fast into your Canadian systems.
The honest residual is the model. Anthropic has no Canadian region today, so Claude processes in the US at rest. You don't pretend that away, you isolate it: ZDR plus pinning inference geography to the US plus documenting the cross-border transfer for your law society. That keeps the cross-border exposure to a single model call instead of the whole pipeline. Full detail in Clio's Canadian region and Claude residency.
Zoom transcripts: the boring path is the reliable one
If your workflow starts from a recorded consult, the cloud-recording VTT transcript is the dependable backbone. Cloud recording and transcription both have to be on, which needs a paid Zoom tier, and the transcript is typically ready about twice the meeting length, so design for delay. The tempting shortcut, pulling Zoom's AI Companion summary through the API, is fragile: the read scope is blocked in Server-to-Server OAuth (you need a General or Account-Managed app), and those summaries auto-delete at 30 days. Treat the AI summary as best-effort and summarize the VTT yourself if it isn't there. We cover the OAuth limitation in this Zoom post.
The Duty You Can't Automate Away
Whatever platform you build on, one thing doesn't change. Guidance from bodies like the Law Society of Ontario and ABA Formal Opinion 512 is converging on the same duties: confidentiality, competence, supervision, and mandatory human verification of AI outputs. You also can't bill AI processing time as if it were lawyer hours.
In build terms, that means a human-review gate belongs in the workflow by design, before the work product is finalized, not bolted on after. A good legal automation drafts and stages; a lawyer reviews and signs off. If a vendor sells you a pipeline that writes final work product with no review step, walk away. More on the ethics framing in our LSO vs ABA 512 comparison.
So, Clio or MyCase?
Here's the decision boiled down, framed as questions to ask yourself rather than a winner we declare:
- Already standardized on one? Automate it. The switching cost across a firm almost always dwarfs the API delta. We've seen firms run Clio, MyCase, and PracticePanther happily, and the automation question is independent of which they chose.
- Workflow leans on custom fields and document write-back? Clio's documented surface (custom-field PATCH, presigned-S3 upload, seven webhook types) gives you more to plan against, which lowers discovery risk.
- On MyCase? It's a capable platform; just verify the exact write paths your workflow needs against your account and plan before anyone quotes a fixed scope. Thinner public docs means more upfront discovery.
- Worried about a Canadian or US data boundary? That's a model-layer problem (ZDR, US-pinned inference, documented cross-border), not a Clio-vs-MyCase problem.
Generic comparison sites like Arkenea or Topflight can tell you which has a nicer client portal. What they can't tell you is whether the API will let your automation write the field you actually need, because they haven't shipped the connectors. We have, for both. That's the difference between a comparison and a guess.
Next Step
If you're weighing a Claude automation on Clio or MyCase and want a straight answer on whether your specific workflow is feasible, what will write back cleanly, what needs net-new connector work, and where the data-residency line falls, we'll look at it with you.
We offer a free 30-minute architecture review. No pitch deck, just an honest technical read on what's automatable on your stack and what isn't.
Book a free architecture review →
Or read more from the work behind this post: