Veterinary software suppliers increasingly say the right thing about data ownership:
the practice owns its data.
But ownership is only part of the story. Part 1 explains why.
A modern veterinary practice may want its PMS to connect to laboratories, accounting software, online booking, payment systems, analytics, pharmacies, client apps, AI services and future tools that do not exist yet.
Those connections increasingly depend on APIs.
So there is a second question every practice should ask:
If we own the data, can we authorise another system to access it without the incumbent PMS controlling the commercial relationship?
What an API changes
An API is simply a structured way for one software system to communicate with another.
For a veterinary practice, that can mean automatically sending invoices to accounting software, receiving lab results, synchronising appointments or allowing an authorised analytics tool to query operational information.
Without a usable API, data may technically belong to the clinic but remain difficult to use outside the PMS.
That gives API terms strategic importance.
Merlin can charge for API access
Merlin's published terms say API use may be subject to Professional Services Fees and a separate quotation.
The same section gives MWI sole control and discretion over the API's development, functionality and operation. MWI can also modify the format of Customer Data and the means by which it is accessed.
Source: Merlin Terms and Conditions, clause 6
The terms also contemplate suspension of API or third-party-solution access in specified circumstances involving unpaid third-party fees.
That creates a clear distinction:
- the clinic owns the Customer Data;
- MWI controls the technical interface through which another service may access it.
There can be good reasons for API governance. A PMS cannot safely allow unknown software to write arbitrary clinical data into its database.
But security controls and commercial gatekeeping are not the same thing.
Practices should understand which one they are paying for.
Vetspire requires approval and can charge integration fees
Vetspire's public terms take a similar controlled-integration approach.
They say third-party API access requires Vetspire's prior written approval and an API Agreement. The terms also provide for applicable certification or integration fees.
Source: Vetspire Terms & Conditions, sections 2.7 and 2.8
Vetspire is a US/international comparison rather than evidence of a standard UK contractual position.
But it illustrates the procurement question neatly:
Does the clinic decide which software can use its data, subject to reasonable security standards, or does the PMS supplier retain a separate commercial veto?
ezyVet raises a different issue: migration tooling
ezyVet's Private API Terms contain one of the more interesting restrictions we found, but it needs to be described accurately.
These are integration-partner terms, not the standard contract between ezyVet and a veterinary clinic.
Under section 3.2(h), an integration partner must not build conversion functionality that converts ezyVet User Data for use on a competing product or service.
Source: ezyVet Private API Terms and Conditions, section 3.2(h)
That does not justify saying "ezyVet contractually prevents clinics from switching PMS". The clause does not bind the clinic in that way.
But it may affect the surrounding ecosystem.
If independent integration developers are contractually restricted from building tools designed to convert ezyVet data for competing systems, that can make automated migration tooling harder to create.
For a practice evaluating long-term portability, integration-partner rules can therefore matter even where they are not part of the clinic's own agreement.
API control can become a switching barrier without anyone saying "lock-in"
This is why software lock-in is often more subtle than a five-year contract.
Imagine a clinic has ten years of records in its PMS.
A new supplier offers a better system and wants to build an automated migration.
The old PMS does not need to forbid the clinic from leaving. It can create friction through:
- paid API access;
- restricted scopes;
- approval processes;
- limits on bulk extraction;
- restrictions imposed on integration partners;
- proprietary formats; or
- the absence of a documented export interface.
Each restriction may have a plausible reason on its own.
Together, they can determine whether switching takes two days or six months.
Security is a valid reason to restrict access
The answer is not "every API should be completely open".
Clinical systems hold personal data and sensitive operational information. Write access can alter patient records, appointments, invoices and medication information.
A responsible PMS should authenticate integrations, log activity, enforce scopes, rate-limit requests and remove access from compromised applications.
It may also need a certification process for software that writes into clinical records.
The relevant distinction is:
reasonable technical control versus unnecessary commercial control.
For example, requiring secure OAuth credentials is a technical safeguard.
Requiring a clinic to pay the PMS vendor simply because it wants its authorised accountant's software to read its own invoice data is a commercial decision.
Practices should know which model they are buying.
Five API questions to put in the tender
Before selecting a PMS, ask:
1. Is there a documented API?
Do not accept "we integrate with lots of partners" as the same answer.
2. Can the practice authorise access itself?
Ask whether every integration needs vendor approval and what criteria are used.
3. Is read access to our own data chargeable?
Separate ordinary API access from bespoke development work.
4. Can we use the API to export data for migration?
This is crucial. Ask whether bulk extraction or migration use is restricted.
5. What happens if we choose a competing supplier?
Ask whether any contractual, technical or partner-policy restriction prevents a third party from helping the clinic move its records.
Get the answers in writing.
The principle is simple
The clinic does not need uncontrolled access to the vendor's software source code.
It does need meaningful control over the data it created.
A sensible model is:
- the practice owns its data;
- the PMS provides a secure documented interface;
- the practice chooses which third parties to authorise;
- the PMS enforces technical and security standards;
- genuinely bespoke integration work can be charged separately; and
- migration to a competing PMS is not treated as prohibited behaviour.
That turns data ownership from a line in a contract into something the clinic can actually use.
Because in a modern software system, the important question is no longer just:
"Who owns the database?"
It is:
"Who controls the door?"
Contract analysis, not legal advice. The ezyVet source discussed above is an integration-partner agreement, not a clinic customer agreement. Individual customer and partner contracts may differ. Sources reviewed on 2026-08-20.