Zonara works alongside ServiceTitan.
Your office already runs on ServiceTitan. Zonara answers the calls it can’t get to — after hours, during the rush, when everyone is on another line — and books the work straight onto the board your dispatcher is already watching.
Nothing gets ripped out.
Your team keeps working where it already works. Zonara answers what the office can’t get to and writes the result back.
The booking lands where dispatch already looks
When Zonara books a call, the job appears in ServiceTitan like any other job — right business unit, right job type, right customer. Nobody retypes anything between the phone and the schedule.
Follow-up runs off your real data
Zonara reads appointment status, estimates, and invoices, so missed-call recovery, no-show rebooking, and unsold-estimate follow-up work from what actually happened in ServiceTitan — not from a separate list somebody has to maintain.
Availability is checked before a time is offered
Zonara reads your capacity before it offers a slot, so the times it promises a customer are times you can actually staff.
What Zonara reads and writes.
This list is exhaustive. Zonara asks for the access its shipped features actually use, and nothing beyond it.
Reads from ServiceTitan
- Customers — name, phone, email, service address
- Appointments and jobs — schedule, status, assigned tech, value, job type
- Estimates
- Invoices
- Capacity and availability windows
Writes back to ServiceTitan
- Create a customer when an unknown caller books
- Create a job (or a booking request where a job isn’t possible)
- Reschedule an appointment
- Cancel a job with a reason
Zonara runs an incremental sync every 15 minutes using the vendor’s own "modified since" cursor. Where a push webhook is available it acts purely as a doorbell: it tells Zonara to re-poll, and its payload is never trusted as data.
Not read: Payroll, pricebook cost data, employee compensation, and accounting ledgers are never read.
A write that fails goes to a durable retry queue rather than being dropped, and if it keeps failing it is escalated to a person instead of retrying forever. A problem writing to ServiceTitan never voids the customer’s booking — Zonara keeps its own record of every contact and appointment, so no integration is a single point of failure. Read the security detail →
Your administrator authorizes Zonara from inside ServiceTitan.
ServiceTitan connections are granted per account by an admin with the API application permissions. Nothing is installed on any computer, and Zonara never asks for anyone’s ServiceTitan password.
- 1A ServiceTitan admin goes to Settings → Integrations → API Application Access.
- 2They connect Zonara and allow access, which generates a client ID and client secret.
- 3Those credentials go into your Zonara location settings, along with your tenant ID and the business unit, job type, and cancellation reason Zonara should use when it books.
Zonara is a layer on top, not a replacement underneath.
Your phone number stays where it is — calls forward, they are never ported. Your team keeps working in ServiceTitan. Every job Zonara books appears there like any other job, so the schedule your dispatcher trusts is still the schedule that runs the day.
Credentials are stored server-side per location, never exposed to a browser and never written to a log. You can revoke Zonara’s access from inside ServiceTitan at any time.
- ServiceTitan has no native no-show status, so Zonara reads a cancellation reason containing "no show" to drive no-show recovery.
- A booking request is not yet a job: until your office converts it, Zonara can’t reschedule or cancel it through the jobs API, so it raises it for a human instead of retrying.
Keep ServiceTitan. Add the front office.
No migration, no porting, no replatforming. Zonara augments the system you already run.