Zapier case study

Referral forms that create Cliniko patients with the right custom fields for each funding scheme

Built white-label inside an Australian digital agency's Zapier workspace, for an Australian allied-health clinic that runs on Cliniko. One Zap turns an online referral into a patient record: a code step normalises the referral and works out how the client is funded, and Paths send a different request to the Cliniko API for each funding scheme, so each record carries its scheme's custom-field sections. It is now off.

An Australian allied-health clinicAllied healthBuilt 20251 Zap for this client, in a 27-Zap agency workspace

funding-scheme paths, each with its own Cliniko request: 3
steps from referral form to patient record: 9
referral details normalised by the code step: 7

The business

This work was delivered white-label, inside the Zapier workspace of an Australian digital agency that builds and runs WordPress and Gravity Forms sites for its clients. The agency is not named, and neither is its client. Each client has its own folder in the workspace; this page covers one of them, and the agency's other clients are written up on their own pages.

The clinic is an Australian allied-health practice. Its clients are referred by GPs, support coordinators and other agents, and funded through different schemes, among them the Department of Veterans' Affairs (DVA), the National Disability Insurance Scheme (NDIS) and home-care packages. Cliniko is its practice-management system, and referrals arrive through a Gravity Forms form on its website.

Each scheme needs different details on the patient record: who referred the client, who manages their plan and where invoices go. Cliniko keeps those in custom-field sections, and the Zap writes them with raw requests to the Cliniko API, one payload per scheme. Our article on Cliniko integration covers the API's rules and the intake-form design we would use now.

Audited 21 Oct 2026. The agency's workspace holds 27 Zaps for several clients; the audit lists 1 in this client's folder, and it is off. Pro plan (annual), 750 tasks a month, resetting on the 22nd; this period's 750 plan tasks and 100 pay-per-task tasks are used up. Autoreplay off. The Zap's usage is 0, so there are no task, run or error figures.

What we built

Referral to patient record

One instant Zap with a code step and three paths, each ending in its own request to the Cliniko API.

Instant9 steps
Referral form to a Cliniko patient, by funding scheme
- Gravity Forms
- Code by Zapier
- Paths
- Webhooks
Trigger
Gravity Forms – Form Submission on the referral and client-intake form
What it does
A JavaScript step normalises the referral details (appointment type, GP, referring agent, support coordinator, primary contact, address and home-care-package provider) and works out the client's funding type. Paths then split three ways, DVA, NDIS and a third funding type, and each path's custom POST request to the Cliniko API creates the patient with consent flags, address, the AU country code, appointment notes (client type and the plan manager's billing email) and the custom-field sections for that scheme.
The tricky part
A different API payload per funding scheme, so each record carries the custom fields its scheme needs, with custom code to normalise the referral before anything is sent.
Error handling
None.
Usage
0.
Status
Off, version 7 plus an unpublished draft, last edited 1 Aug 2025

Data handling

The Zap creates patient records from referrals, so it handles health and referral information. The audit viewed step configuration only: no run or patient data was opened, and nothing about any patient appears on this page. A build like this sits under the clinic's own privacy obligations, which were outside the audit.

What the counters show

The Zap is off and its usage is 0, so there are no run, task or error counters to report.
What the folder shows is the design: one referral form, a code step that decides the funding type, and a separate Cliniko API request for each scheme, so veterans' affairs, disability-insurance and home-care-package clients each get the fields they need.

What we would change

The Zap is off, so referrals do not reach Cliniko automatically today, and an unpublished draft sits beside version 7. We would settle which version is wanted before switching it back on.
Every path creates a patient and none searches first, so a client referred twice, or one already in Cliniko, would get a second record. We would search Cliniko by email and date of birth and create only when there is no match, the duplicate rule our article on Cliniko integration sets out.
There is no error handling and autoreplay is off in the workspace, so a rejected request leaves a referral with no patient record and nobody told. We would add an error path that alerts the clinic.
A Webhooks request keeps its credentials in the step's own fields. We would move the Cliniko API key into an API by Zapier connection, which Zapier recommends for authenticated requests.

Nothing was left out: this is the only Zap the audit lists for this client.

Built with

Zapier
Gravity Forms
WordPress
Cliniko API
Code by Zapier
Paths
Webhooks

Next Zapier accountIn-app subscription changes mirrored to a user sheet and the right Mailchimp segmentA subscription surf-forecasting app

Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy

Start here

Have a Zapier account like this one?

We start by reading what is already there: every Zap, its counters and its failures. A short call is the fastest way to find out what yours needs.

Book a 15-minute call saveez@skofi.tech

What happens on the call

15 minutes, no deck
We map the process on the call
A written scope, or an honest no