Zapier

A Zap watches for something in SmileLine — a new enquiry, an enquiry won, a new review — and then does something in another app. It works the other way too: a Zap can create a lead, a patient, a task or a note in SmileLine. No code is involved on either side.

Before you connect

• Only owners and managers can authorise a connection. Coordinators, telesales and analysts can see the connection afterwards but cannot create one.
• A connection belongs to one practice and one region, fixed at the moment you approve it. It cannot be re-pointed at another practice later — connect again for each practice you run.
• A connection acts as the person who authorised it. It can read and change exactly what that person can, and every change it makes is recorded in the activity log under their name with an API key marker, so a Zap's work is never presented as someone sitting at a keyboard.
• Removing that person from the practice stops the connection working.

Connect SmileLine to Zapier

What a Zap can trigger on

Five of these report a change rather than something new: Enquiry Won, Enquiry Lost, Enquiry Stage Changed, Appointment Status Changed and Deposit Requested or Status Changed. Every change fires, including a move back and then forward again — nothing is skipped. But a Zap reads the record at the moment it runs, so when several changes land close together you get several runs that can all show the same final state. An enquiry pushed through three stages in a minute triggers three times, and all three may say it is in the third stage.

In practice that means a "when the stage becomes X" Zap can run more than once for the same enquiry. If the Zap does something you would not want repeated — sending a message, charging something, creating a row — key it on the event rather than on the state Zapier reports, and Zapier's own duplicate protection will do the rest.

A trigger hands Zapier the record itself, read back from SmileLine with the connection's access: the patient's name, email address, mobile number, town, postcode, tags and marketing opt-outs on most triggers, and the message text on New Inbound Message. Treat everything a trigger produces as patient data. While you are building the Zap, Zapier shows recent real records as samples so you can map fields before anything has happened — those samples contain real patient details too.

What a Zap can do in SmileLine

Find Patient also pairs with Create Patient as a single Find or Create Patient step, so a Zap can say "use this patient, or add them" without a filter in between.

How quickly triggers fire

Most triggers arrive within about five minutes. SmileLine stores every event durably the moment it happens, then a sweep hands it to your Zaps on a five-minute cycle. A Zap that has not started yet is normally waiting for the next sweep rather than failing — nothing is dropped in between.

If a Zap's delivery fails, SmileLine retries it on a widening schedule for up to 48 hours. Twenty consecutive failures pause that Zap's subscription; turn the Zap off and on again once the problem is fixed.

Each switched-on trigger uses one endpoint

A practice can hold 20 webhook endpoints, and every switched-on Zap trigger takes one. Actions and searches take none, so a Zap that only writes into SmileLine costs nothing against the limit.

Turning a Zap off gives its endpoint back, and turning it on again takes one back — the count never leaks. If an earlier attempt was interrupted, switching the Zap on repairs the same endpoint instead of spending a second slot.

An endpoint that SmileLine paused is the exception. A pause is either someone's deliberate choice or the automatic stop after twenty consecutive failed deliveries, and neither should be undone by switching a Zap on and off. Resume it under Settings → Integrations first.

At the limit, Zapier refuses to switch the Zap on and says so:

Your SmileLine organization has reached its limit of 20 webhook endpoints.
Turn off an unused Zap, or remove an endpoint in SmileLine, then turn this
Zap on again.

Turn off a Zap you no longer need, or archive an endpoint you created yourself through the webhooks API, then switch the Zap on again.

How Create Lead avoids duplicates

Create Lead never creates the same enquiry twice:

• Fill in Dedupe Key with a stable id from the source system — an order number, a form submission id. Sending the same key again with the same details returns the original lead instead of making another one.
• Leave Dedupe Key blank and SmileLine uses a fingerprint of the details themselves, so a Zap that retries after a timeout still cannot double up.
• Reusing a key with different details is refused, so a copied-and-pasted key cannot quietly overwrite an earlier enquiry.

Separately, a lead whose email address or mobile number matches an existing patient is attached to that patient rather than creating a duplicate record.

Every lead needs a first name, a Treatment, and either an email address or a mobile number. Give the mobile number in full international form, for example +447700900123.

Occasionally the step reports the lead as queued rather than created. That is still a success: the enquiry has been stored safely and is processed automatically a few minutes later. Do not re-send it.

Where Zapier leads appear

The first time a Zap creates a lead, SmileLine adds a capture form called Zapier under Settings → Website. Every lead from Zapier arrives through it, so:

• new enquiries land on the Today page in real time, like any other lead;
• the form's Deliveries tab shows exactly what Zapier sent, including anything rejected;
• marketing parameters you map on the action — UTM values, Google Click ID, Meta Click ID, the landing and capture URLs — become the lead's attribution record; and
• automations enrol these leads exactly as they do website enquiries.

Leave that form in place. If you archive it, SmileLine simply provisions a fresh one the next time a Zap sends a lead — but any lead that was waiting to be retried at that moment lands in the review queue for a person to decide on, rather than healing itself.

Disconnect Zapier

You can stop the connection from either side:

• In Zapier — turn off a single Zap to release its endpoint, or delete the SmileLine connection under My Apps to stop every Zap that uses it.
• In SmileLine — disconnect the app from the practice. This is the stronger action: it stops the connection working on its very next request rather than when its token would have expired, and it switches off the webhook endpoints the connection created, including anything already queued for them. See Connected apps.

Disconnecting removes access. It does not remove any data: leads, patients, tasks and notes a Zap created stay exactly where they are, and data already copied into Zapier or into the apps beyond it is outside SmileLine's reach — delete it there yourself.

Build your own instead

Zapier is a convenience, not the only route. If you would rather integrate directly, everything the Zapier app uses is a documented, supported surface: OAuth connections for credentials, POST /leads for lead intake, and webhooks for events.