Free setupLive in 7 days30 leads in 30 days or your money back
Home  /  Industries  /  Optometry  /  Booking systems
Optometry · booking systems

The one system with a full API runs on your local network.

Australian optometry has exactly one practice system with a complete public API specification, and it is designed to run inside the practice. That is not a blocker, and it is the reason integration here costs more than agencies expect.

The capability picture

What is actually documented.

Assessed by reading the vendor specification itself rather than the marketing pages, which is why this is more specific than any comparison you will find elsewhere.

CapabilityOptomate TouchOptomate.NetSunix
Public API specificationYes, full REST with ODataNone foundNone found
WebhooksNone anywhere in the specificationNot documentedNot documented
Click identifier fieldNone native. A 200 character source field can carry itNot documentedNot documented
Line level sale revenueYes, through patient invoicesNot documentedNot documented
Online bookingVia third party layersIntegrated web bookingNot documented on the vendor site
Medicare and HICAPSYesYesYes

Sunix is widely installed in Australian optometry, so the absence of developer documentation is a genuine constraint rather than a criticism. Where a practice runs it, hashed contact matching is the realistic route.

The one trap in the documentation

Turning on the API can turn off your recalls.

The Optomate Touch specification carries a documented side effect that is easy to miss and expensive to discover: assigning access permissions to the patient recalls resource for an API user disables the Recalls Wizard inside the software.

In a business where recall is a primary revenue mechanism, that is not a minor configuration note. It means recalls become either a software function or an API function, and the practice has to choose. Anybody proposing an integration on Optomate Touch should be raising that before the work starts, not after the front desk notices the wizard has gone.

Why local hosting is the real cost
The Optomate Touch API is intended to run locally on the network where the software is installed, and authenticates with HTTP basic authentication against a user created inside the application. That means a cloud based integration cannot simply call it: it needs a tunnel, a VPN or an agent running on site. That is the genuine implementation cost in Australian optometry tracking, it is not difficult, and no agency page anywhere mentions it. If a quote for offline conversion imports does not account for it, the person quoting has not read the specification.
Straight answers

Questions clinic owners actually ask

Which optometry practice system is best for advertising?
Optomate Touch, by a considerable margin, because it is the only one in Australian optometry publishing a full REST API specification. It exposes patient records with contact details and a source field that can hold a click identifier, appointment endpoints supporting reads and writes, and patient invoices with line level revenue. Its limitations are that there are no webhooks so integration must poll, and that it runs on the practice's local network so a cloud integration needs an on-site route in. Optomate.Net and Sunix publish no developer documentation we could locate.
Can a practice on Sunix track Google Ads conversions?
Yes, though not through the practice system. We could not find any public API, developer or integration documentation for Sunix, so a direct data pipeline is not available on published information. The route that works regardless of system is enhanced conversions matching on hashed email and phone, which requires only that you can export a patient list with contact details and a date. It is less precise than a click identifier chain and it means you can still report attended patients and dispensed value back to Google.
Does the booking widget break conversion tracking?
Frequently, yes. Booking widgets from the major Australian directories typically run on the vendor's domain, either embedded or by redirect. Cookies, the analytics session and the click identifier do not cross that boundary, so a conversion configured to fire on a thank you page either fires in the wrong context or not at all. The fix is to pass the click identifier and campaign parameters into the booking URL, configure cross domain linking, and reconcile against the practice system afterwards. No vendor in this stack documents that process.
Should we change practice systems to improve tracking?
No. Practice systems are chosen on clinical records, dispensing, Medicare claiming and recall, all of which matter far more day to day than conversion attribution. The reason to understand the constraint is to know which tracking architecture is realistic on what you already run, and to avoid paying for an integration that cannot be built. On Optomate Touch a full chain is available with an on-site component. On the others, hashed matching is the honest answer.
Related

Booking systems in other clinics

Dermatology booking systemsDental booking systemsPhysiotherapy booking systems
A campaign partnership built for clinics

Ads that earn their place in your P&L.

A senior team that lives inside your account. Conversion infrastructure wired in before any ad goes live. Reporting that ties spend to booked appointments, not impressions.

Dedicated account manager

A senior specialist who runs clinic accounts day to day.

Clinic-only specialists

Every keyword, headline and account structure built inside real Australian clinic accounts.

Award-winning team

Winner, Best Google Ads Campaign, Australia 2025. Google Partner. AFR Fast 100.

When you're ready
We will be too.
Start a conversation →How we work