ServiceTitan/Jobber integration map: what data moves where

An integration map is one page that says, for each AI tool, which objects it reads and writes in your scheduling software, which way, how often, and what happens when it cannot. This guide draws that map for ServiceTitan and Jobber across a voice agent, quote automation and review requests, then shows how to draw it for your own account.

What is an integration map?

A table with one row per flow. Each row names the tool, the object, the system the data leaves, the system it enters, whether the tool is reading or writing, when the flow runs, and what the tool does when the flow fails. The whole map for an office fits on a page, and an owner can read it without knowing what an API is.

The reason to draw it before connecting anything is that every write is a risk and every read is a dependency, and nobody sees either until they are on a page. A voice agent that "books into ServiceTitan" is a sentence; the same agent as three reads and one write, each with a cadence and a fallback, is something you can approve, test, and hold a vendor to. The map is also the document that outlives the vendor.

What does a map cover in ServiceTitan?

The objects below are the typical shape of the platform as an office uses it, named as the office names them; they are not verified against the API reference for your account, and the verified object names and endpoints are Set out in the agreement.

A customer, who is billed. A location, where the work happens, which for a residential customer is usually one and for a property manager is many. A job, the unit of work with a type, a status and the technician assigned. An appointment, the window on the board when a technician is due at the location. Around those four, the objects that money and pricing live in: the estimate, the invoice, and the price book that the estimate is priced from. And the notes and custom fields the office has added over the years, which are where the map usually finds its surprises.

A voice agent touches the customer and the location to identify who is calling and where, the appointment to offer and book a window, and the job to create it with the right type. Quote automation touches the job or the estimate to read what was requested and the price book to price it, and writes the estimate. Review requests read completed jobs and the customer's contact, and write nothing back.

What does a map cover in Jobber?

The same caution: typical shape, office names, not verified for your account; the verified names are Set out in the agreement.

A client, who is billed. A property, where the work happens, of which a client may have several. A request, which is how work arrives: the form on the website, the call the office logs, the message. A quote, priced and sent for approval. A job, the scheduled work with its visits. An invoice. Jobber's shape puts the request first, which is the object a quote tool most wants and the one many offices leave half filled.

A voice agent touches the client and the property to identify the caller, the job and its visits to offer and book a window, and writes the request or the job depending on how the office wants a call to land. Quote automation reads the request and the property, prices from the office's rules, and writes the quote; on acceptance it writes the job. Review requests read completed jobs and the client's contact, and write nothing.

What does a voice agent read and write?

Reads, in the order they happen on a call. The customer or client by phone number, first, so the agent knows who is calling before the caller says. The location or property, so the agent knows where. The job history, so the agent knows what was done before and can say so. The open windows, from the appointments or the visits, so the agent offers a time that is actually free.

One write, last, after every slot the booking needs is filled and the caller has said yes: the appointment or the visit, with the job it belongs to, the type, the window, and the call notes. Then a read-back to the caller of what was booked, from the system, not from memory, so both sides know it happened. A second, quieter write at call end: the summary, the transcript link and the recording where the office looks for them.

The fallback for each read is a question to the caller; the fallback for the write is a person, and the agent says so rather than reading back a confirmation it does not have. The cadence for the reads is live, during the call, because a cached schedule offers a window that was taken a minute ago.

What does quote automation read and write?

Reads: the request or the job as it arrived, with the photos and answers the intake collected; the property or location, for access and past work; the price book or the office's pricing rules, which live in the platform or in a table the office maintains. The cadence for the request read is on the event of its arrival, because turnaround is the number this tool is measured on.

Writes: the estimate or the quote, priced, with line items and the customer-facing text, sent through the platform so the customer sees the office's own branded document. For the first weeks the write is a draft a person approves. On acceptance, which the tool reads as an event, a second write: the job, with the fields the office needs to schedule it.

The fallback for a request missing what the price needs is one ask to the customer, not a guess. The fallback for a price outside the range the office set is a hold for a person. The fallback for a failed write is the draft attached to the request for a person to paste in, with the clock still running so the miss is counted.

What do review requests read and write?

Reads only. The completed job, on the event of completion or on a schedule at the end of the day; the customer's contact and their consent to be messaged; and the record of what was sent before, so nobody is asked twice for the same job. The write, the request message itself, goes out through the messaging channel, Twilio or the platform's own, and the record of having sent it is kept on the tool's side or in a note on the job, depending on what the office prefers.

The fallback is silence: a job with no consent, no contact or a prior request is skipped and logged, never messaged. Review requests are the lowest-risk flow on the map, which is why they are a good first integration for an office that has never connected a tool.

How do I draw the map for my own account?

Follow the five steps. Open the system and list the objects in its names, with the fields the office really fills, on line 1. Decide the system of record for customers, jobs and money, on line 2. For each tool, one line per flow on line 3: object, from, to, read or write. For each line, the cadence and the fallback on line 4. Then the credential each tool runs on, issued by your admin and scoped to the objects on the map, on line 5.

Then test. Each flow on a sandbox or a test account with a record you made for the purpose, checked in the system the office sees, and each fallback forced: revoke the credential, take the system offline, send a duplicate request. Dates on line 6. The rate limit and the error the platform returns when it is hit, verified, on line 7, with the retry policy the tool sets; the verified figures for the two platforms are Pricing on request.

Where does this go wrong?

The map is drawn from the vendor's sales deck instead of from your account, so the objects on it are the ones the vendor's last client had. A field the office added is required for a write and nobody knew, and the write fails on the first live call instead of the first test. Two records exist for one phone number and the agent books the wrong one. The tool runs on the office manager's login, and when they leave, every flow stops. The rate limit is hit on a busy morning and the tool reads it as an outage.

Every one of those is a line on the worksheet. Draw the map before you sign, bring it to a working session, and we will say which objects on your platform each line maps to.