Where Lawmatics reporting starts to pinch
Lawmatics runs intake and marketing automation for roughly 2,000 law firms, and its dashboards are genuinely usable for the canned views: leads by stage, conversion rate by period, tasks due. The friction starts when the question crosses two dimensions, or leans on the custom fields your firm added during setup.
You don't have to take our word for it. The public review record documents the same pattern from paying users: firms saying they "would appreciate if reporting came with basic reports any law firm would want," firms that could not build specific reports natively (one example from the reviews: trust-fund-request reports), and firms discovering that the contact CSV export leaves out matter fields entirely. There is also no test or sandbox environment, so every reporting experiment runs against your live pipeline data.
None of that makes Lawmatics a bad CRM. It makes it a CRM whose reporting layer has a boundary, the same way Clio Grow, Lead Docket, and Captorra each have theirs. The useful question is what to do when your question lands past the boundary. There are four pathways, and each one is right for a specific class of question.
The four pathways, compared
Native reports
walls at custom cross-tabs
CSV export
contact export drops matter fields
Zapier
no custom fields, per-task metering
API / MCP
custom fields, any cross-tab, Claude does the aggregation
| Pathway | Custom fields | Cross-tabs | Best for |
|---|---|---|---|
| Native reports & dashboards | Partial (display, limited grouping) | Walls on custom cross-tabs | Canned pipeline views, stage counts, conversion by period |
| CSV export | No bulk export (API-only) | Only what the export includes; contacts lack matter fields | One-off contact lists, mail merges |
| Zapier | No (absent from Lawmatics actions) | In your spreadsheet/BI, minus custom fields | Event-driven trickle into Sheets or a BI tool |
| API / MCP | Yes (fields= incl. custom_fields) | Yes, aggregated in code or by Claude | Custom cross-tabs, ad-hoc questions, standing extracts |
What do the native reports and dashboards handle well?
The built-in layer answers the questions Lawmatics anticipated: how many leads entered each stage this month, which campaigns are converting, what the intake team's task load looks like. If your question maps onto a view Lawmatics ships, use the native report and move on. It is real time, it costs nothing extra, and nobody has to maintain it.
The wall is custom cross-tabs. Ask for matters broken down by referral source and practice area at the same time, with a custom field as a third column, and you are past what the report builder composes. The documented user complaints above are all versions of this same wall: the report exists in your head, the data exists in Lawmatics, and no native screen joins the two. With no sandbox environment, you also can't safely experiment your way to a workaround on test data; every attempt runs against production.
What does the CSV export actually contain?
Less than you'd assume. The contact export produces a flat file of contact records, and it does not include matter fields. So the export answers "who are my contacts" and cannot answer "which matters came from which source," because the matter side of the join is missing from the file.
Custom fields make it worse. Bulk export of custom-field data is effectively API-only: there is no export screen that hands you every matter with its custom fields as columns. Since custom fields are where intake teams record precisely the data leadership wants cross-tabbed (referral details, case type qualifiers, estimated case value), the export button ends up covering mail merges and one-off contact lists, and little else. It is also manual: someone clicks it, downloads the file, and the file is stale the moment it lands.
Is Zapier a reporting layer for Lawmatics?
Zapier is an event pipe. When something happens in Lawmatics (a lead is created, a stage changes), a Zap fires and writes a row somewhere: Google Sheets, Airtable, a BI tool's intake endpoint. Over weeks, the rows accumulate into a dataset you can chart in Power BI or Looker Studio. For firms that want a slowly self-building spreadsheet without writing code, that is a legitimate pattern.
Two constraints define its ceiling. First, Zapier's Lawmatics actions do not carry custom fields, so the trickle arriving in your spreadsheet is missing the intake data you most want to report on. Second, every record consumes a Zapier task against your monthly plan, so a busy intake pipeline meters your reporting layer per lead. And because the dataset only starts accumulating when you switch the Zap on, it contains no history: the report you want today needs data from the last twelve months, and Zapier was not watching. We wrote a fuller head-to-head in Lawmatics MCP vs Zapier.
What does the API route give you, and what are its real constraints?
The Lawmatics REST API (api.lawmatics.com/v1) is the only pathway that returns everything, including custom fields via the fields= selection parameter with custom_fields. Access is free but gated: you email api@lawmatics.com to have Developer Settings enabled on your account. Authentication is OAuth2, and the tokens never expire, which is convenient for standing integrations and worth knowing for your security review (a leaked token stays valid until you revoke it, so store it like a password, and revoke tokens when staff with access leave).
The constraints that shape any integration:
- Pagination is fixed at 25 records per page. A 4,000-matter pipeline is 160 sequential requests. Plan for it.
- One filter per request. "Practice area = PI AND source = referral" is two round trips plus client-side intersection, or one broad pull filtered locally.
- The rate limit is documented inconsistently: 50 requests per minute in one place, 150 in another. Build to 50/min and you will never be surprised.
- Webhooks are dashboard-configured only, across 13 event types. There is no API endpoint to register them programmatically.
- No API pathway moves matters between pipeline stages. The API route is read-heavy by design: reporting and syncing work, remote pipeline manipulation does not.
Within those constraints, the API supports two working patterns. Pattern one is a scheduled extract: a script pages through matters nightly, lands them in a database or warehouse, and Power BI or Looker Studio sits on top. That is the right shape for standing dashboards. Pattern two is conversational: an MCP connector gives Claude direct read access, and Claude handles the pagination, the filter juggling, and the aggregation when you ask a question in plain English. We published the open-source Lawmatics MCP server for exactly this: @oktopeak/lawmatics-mcp v1.0.0 on npm, MIT-licensed, 37 tools, the first Lawmatics server in the official MCP Registry, with a read-only mode via LAWMATICS_READ_ONLY=1. The setup guide walks through the api@lawmatics.com unlock and the OAuth flow step by step.
Honest scope note: the connector is built from Lawmatics' official API documentation and has not yet been verified against a live firm account. The docs are what they are (see the 50-vs-150 rate limit above), so treat your first connection as a shakedown run: start in read-only mode, ask questions whose answers you can verify in the Lawmatics UI, and report anything that disagrees. The repo is public: github.com/oktopeak/lawmatics-mcp.
Can I connect Lawmatics directly to Power BI or Looker Studio?
Not natively. Lawmatics ships no BI connector, no warehouse product, and no supported ODBC feed, so a BI dashboard gets assembled from the pathways above: a manual CSV drop (with the matter-field and custom-field gaps), a Zapier trickle (no custom fields, no history), or an API extract that lands the data in a database Power BI or Looker Studio reads. The API extract is the only one of the three that delivers complete data, and the constraints make its runtime predictable: at 25 records per page and the conservative 50-requests-per-minute budget, a 10,000-record pipeline is 400 requests, roughly 8 minutes per full refresh. Run it nightly and the dashboards are never more than a day behind, which is enough for pipeline management at every firm size we have seen.
A worked example: matters by source and practice area, with intake custom fields
Matters by source and practice area for last quarter, with the "injury type" intake field, hired only.
demo data
Take the report a managing partner actually asks for: every matter opened this year, broken down by referral source and practice area, with two intake custom fields (estimated case value and how the client heard about the firm) as columns. Run it through each pathway.
Pathway 1, native reports: fails on the cross-tab. You can see leads by stage, and you can see some source breakdowns, and the two-dimensional source-by-practice-area grid with custom-field columns is past what the builder composes. This is the wall the "basic reports any law firm would want" complaint describes.
Pathway 2, CSV export: fails on the data. The contact export has no matter fields, so practice area and matter-level source are absent from the file. The custom fields you want as columns have no bulk-export screen at all. There is no amount of Excel skill that recovers columns the file never contained.
Pathway 3, Zapier: fails on both history and custom fields. A Zap switched on today has no record of the matters opened in January through July, and the Lawmatics actions would not carry the two custom fields even for the matters it does see going forward.
Pathway 4, API/MCP: this is the query the API was built for. A script (or Claude, through the MCP connector) pages through this year's matters 25 at a time, requests custom_fields via the fields= parameter, groups by source and practice area client-side, and emits the grid. On a 2,000-matter year that is 80 requests, under two minutes even at the conservative 50/min limit. Through the connector, the whole thing is one sentence typed at Claude, and the follow-up ("now just the PI matters over $50K estimated value") is one more sentence rather than a second engineering ticket.
Which pathway for which firm
Solo and small firms with a standard pipeline: stay native. The dashboards cover stage counts and conversion, and the questions past the wall come up rarely enough that a one-off manual workaround is cheaper than any infrastructure.
Firms whose partners ask ad-hoc questions weekly: the MCP route earns its keep fastest here, because the marginal cost of the next question is zero. The connector is free and open source; if you want it installed, configured, and tested against your account by someone who has done it before, that is what our guided MCP setup covers.
Firms that want standing dashboards on a wall: the scheduled-extract pattern into Power BI or Looker Studio is the right architecture, and the API constraints above (25/page, one filter, 50/min) are the spec sheet for whoever builds it.
Firms running Lawmatics next to Clio: your reporting problem is usually double, because the pipeline lives in Lawmatics and production lives in Clio, and neither system's reports see the other's data. That two-system stack has its own economics and its own escape routes; we covered them in Clio + Lawmatics: what the two-system stack really costs.
Three mistakes that sink Lawmatics reporting projects
First, discovering the export gaps in week three. Teams promise leadership a dashboard on the assumption that "we'll just export everything," then find the contact CSV has no matter fields and the custom fields have no bulk-export screen, and the project restarts around the API with the deadline already spent. Check the data path before promising the dashboard.
Second, building to the optimistic rate limit. One documentation source says 150 requests per minute, another says 50, and an integration built to 150 fails intermittently in ways that look random until someone reads both pages. Build to 50 and the failures stop.
Third, testing against the live pipeline as if a sandbox existed. There is no test environment, so every experimental automation and every trial import touches production. The working discipline is boring: create clearly tagged test contacts, filter the tag out of every report, and delete them on a schedule. Untagged test records sit inside your conversion metrics and skew them silently.
FAQ
Can I export all my data from Lawmatics to a spreadsheet?
Partially. The contact CSV export works but omits matter fields, and bulk custom-field export is effectively API-only. Matter-level data with custom fields comes out through the REST API, directly or via an MCP connector.
Does Zapier sync Lawmatics custom fields?
No. Zapier's Lawmatics actions carry standard fields only, and each synced record consumes a Zapier task. Custom-field reporting needs the API pathway.
What are the Lawmatics API rate limits and pagination rules?
Fixed 25 records per page, one filter per request, and a rate limit documented as both 50/min and 150/min in different places. Build to 50/min. Access is free after emailing api@lawmatics.com to unlock Developer Settings; OAuth2 tokens never expire.
Can the Lawmatics API move a matter to a different pipeline stage?
No. There is no API pathway for stage moves as of mid-2026, and webhooks are dashboard-configured only (13 event types). Treat the API as read-heavy: reporting and syncing yes, remote pipeline manipulation no.
Can I ask Lawmatics questions in plain English with Claude?
Yes, through the open-source @oktopeak/lawmatics-mcp connector (MIT, npm, 37 tools, read-only mode available). It is built from the official API docs and not yet verified against a live firm account, so start in read-only mode and cross-check the first answers against the Lawmatics UI.
If the report you need is stuck behind one of these walls, the fastest way to pick a pathway is to name the report. Bring the cross-tab you can't build to a 30-minute call and we will tell you which of the four routes fits, including the two that involve no work from us.
Sources: Lawmatics API documentation (api.lawmatics.com/v1), Lawmatics help center, public user reviews on Capterra and G2, Zapier's published Lawmatics integration actions, and our own integration work building @oktopeak/lawmatics-mcp from the official docs.
