If you are building software for veterinary practices, the hardest engineering problem in front of you is probably not your product. It is getting permission to read and write the practice's own records, which live in its practice information management system (PIMS), and paying for that permission once you have it.
The best public evidence on this comes from the Companion Animal Veterinary Software Guide (CAVSG), a research series published between January and May 2026 by Jon Ayers, former chairman and CEO of IDEXX Laboratories, with Adam Wysocki, Adam Little and Jeff Dixon. Its surveys covered 1,273 North American practices and roughly twenty independent software vendors (ISVs). The authors disclose an explicit pro-openness position and some investment interests, so read their framing with that in mind. The fee numbers below come from developers describing their own contracts.
Every developer needs the data, and nobody rates the ecosystem as open
In CAVSG Part VIII, every ISV surveyed said read access, write-back access or both is important to delivering full value to practices, and every one said they would prefer a PIMS-sanctioned integration path. Not one said PIMS data was unnecessary.
Asked to rate the openness of the veterinary PIMS ecosystem as a whole on a 1 to 5 scale, the 18 responding ISVs gave it an average of 1.94. No ISV rated it above 3. Weighted by practice share across the 14 systems covered, the per-PIMS average was 2.23 (CAVSG Part IX, second edition). The researchers' summary of the gap is worth quoting: "the whole is worse than the sum of its parts."
| Measure | Figure | Source |
|---|---|---|
| ISVs saying PIMS read and/or write access is important | 100% | CAVSG Part VIII |
| ISVs preferring a sanctioned integration path | 100% | CAVSG Part VIII |
| Ecosystem openness, ISV-rated (1 to 5) | 1.94 | CAVSG Part VIII (18 ISVs) |
| Per-PIMS openness, practice-share weighted | 2.23 | CAVSG Part IX, ed. 2 (14 PIMS) |
| Highest ecosystem rating any ISV gave | 3 or below | CAVSG Part VIII |
Openness is uneven rather than uniformly low. In the CAVSG data, the five PIMS rated most open were all independent cloud systems covering a minority of practices, and the least open were concentrated among the systems with the most installations. For a developer, that means the easiest integrations reach the fewest clinics.
What the fees look like
Part IX, second edition, collects the most specific public record of veterinary API pricing so far. Developers described it under several structures:
| Structure reported by developers | Example figures |
|---|---|
| Middleware for an on-premise estate | About $5,000 setup plus $65 to $85 per clinic per month |
| Large cloud PIMS, upfront | $50,000 to $100,000 upfront, or per-clinic monthly fees plus revenue share |
| Large cloud PIMS, certification model | Upfront cost "in the thousands" plus an ongoing monthly fee |
| Designated middleware partner for a diagnostics ISV | $20,000 one-time plus $3,000 per month |
Source: CAVSG Part IX, second edition, p. 29. Individual contracts are covered by NDAs; the figures are as reported by ISV respondents.
The fee on its own is not the issue. The issue is the fee relative to what you sell. In the report's words, "a $30 per month API cost is unsustainable when your product sells for $50 per month." Three respondents independently estimated that integration fees of $30 to $85 per clinic per month can consume 10 to 20 percent or more of revenue per clinic.
Run the arithmetic on a few price points and the pattern is plain:
Run the arithmetic on a few price points and the pattern is plain:
Illustrative arithmetic using the fee range reported in CAVSG Part IX, ed. 2.
A flat per-clinic fee is regressive. It barely registers for a product priced at several hundred dollars a month and it can erase the margin on a focused $50 tool. The report puts it precisely: the fee structure filters "on ISV pricing model rather than on product quality."
That matters more in veterinary software than in most markets, because the products gaining ground are often narrow ones. CAVSG Part VII found independent AI scribes holding about 80% of scribe users against under 9% for scribes built into a PIMS, with much higher satisfaction. Focused tools are winning, and focused tools tend to be the cheap ones the fee hits hardest.
Why fees exist, in the vendors' own words
It would be easy to read all of this as gatekeeping, and some of it is. The vendors' side deserves a fair hearing, because it tells you what they will negotiate on.
PIMS vendors that charge describe the fees as infrastructure cost recovery, funding for a partner program, or the cost of scaling governance as more third parties touch clinical data. Some waive fees for early-stage and smaller developers. One of the largest vendors told the researchers it is targeting free, self-service API access in the second half of 2026 (CAVSG Part IX Companion). Every fee-charging respondent said partners may disclose the fee's existence, amount and billing method to the practice.
That last point is useful. You are allowed to show a clinic what integration costs, so you can make it visible instead of burying it in your price.
How to plan a product around the tax
Price for the fee before you sign up for it. If your target PIMS charges per clinic per month, model your gross margin at the fee's upper bound for your smallest customer. If it breaks at $50, either your price or your first integration target is wrong.
Sequence integrations by openness, not by market share. The largest installed bases are also where access is hardest and most expensive. Launching on the more open cloud systems first gets you working integrations, real users and reference customers, which strengthens every later negotiation.
Design for read first, write-back second. Read access alone often lets you deliver value and prove demand. Write-back is where vendors add certification requirements and where your liability for record integrity begins. Plan the write path carefully, with idempotent operations, clear ownership of each field you touch, and a record of every change.
Pass the fee through transparently when you have to. Since vendors permit disclosure, a line item that says "integration fee charged by your practice software" moves the pressure to the party who can change it. Practices are paying attention. CAVSG Part VI found 88% of practices rate third-party integration as important.
Avoid unsanctioned access as a strategy. Screen reading and other workarounds are getting easier with agentic AI tools, and CAVSG quotes developers who expect them to erode gatekeeping. They also put you on the wrong side of the practice's data governance and of the vendor relationship you will eventually need. Every ISV in the survey said they would rather have a sanctioned path. Build as if you will get one.
Where this is heading
The trend points toward more openness, driven partly by practice demand, partly by agentic AI making closed systems harder to keep closed, and partly by vendors deciding an ecosystem is worth more than a toll. None of that helps a developer shipping this quarter.
For now, the integration tax is a real line in your cost model and a real reason small veterinary tools fail. Treat it as a design constraint from day one.
We are building viggoVet as a platform that works alongside whatever system a practice already runs, with a developer program designed around this problem. More on how we are approaching it in future posts.
References
- (2026). CAVSG Part VIII (April 2026): ISV openness survey, 1.94/5 ecosystem score, 100% need read/write, 100% prefer sanctioned path. Local copy: `Research/companion-animal-veterinary-software-ai-paper-part-8.pdf`. Public:Link
- CAVSG Part IX, second edition (11 May 2026), p. 29 (Barrier 4, monetization of API access; fee figures; (2026). $30 per month
- (2026). CAVSG Part IX Companion (8 May 2026): vendor targeting free self-service in 2H 2026
- (2026). CAVSG Part VII (April 2026): independent vs PIMS-embedded scribe share
- CAVSG Part VI: 88% of practices rate integration important
- Part I public URL confirming the host:Link
