ServiceTitan AI integration, end to end.

Read only, report out. The layer replicates the records it needs, reasons over them, and emits a report or an email. Nothing is written back. Lowest integration risk, fastest to ship, and the right shape for consolidated cross-brand reporting where the output is a document a human reads on Monday morning.

Read and suggest. The layer reads, produces a recommendation, and writes it somewhere a human sees it inside ServiceTitan, then a person accepts or rejects. This is the default for anything touching dispatch, pricing or a customer commitment. It needs write permission, but every write is a proposal rather than an action.

Event-driven write-back. The layer reacts to a change, does work, and writes a real record. This is where idempotency, retry policy and error routing stop being theoretical. Every write path needs a key that makes a retry safe and a dead-letter destination a human checks.

Front door. The layer sits ahead of ServiceTitan and originates records, most commonly a voice agent answering inbound calls and creating bookings. Heaviest, because the AI is now the first thing a customer touches and a failure is a lost call rather than a bad suggestion. Covered in its own fold below.

Pick the lightest pattern that solves the constraint. Roughly speaking, the cost of an engagement tracks this list far more than it tracks anything about the model.

The mental model that trips people up first: your integration is an app, not a user. You register it on ServiceTitan's developer portal, the tenant installs it and grants permissions, and from then on the app authenticates as itself using the OAuth client credentials flow. The token that comes back is short-lived, so cache it with an expiry margin and refresh on a timer rather than on a 401.

Alongside the bearer token, requests carry an app key header. Two credentials, both required, and a missing app key produces an authorization failure that looks like a bad token. That single confusion accounts for a surprising share of the first day of any ServiceTitan integration.

ServiceTitan also runs a separate integration environment with its own host and its own credentials. Build there. Test every write path there. The provisioning of that environment is a dependency on the tenant admin and on ServiceTitan, and it is not instant, so raise it in the kickoff call rather than the week you need it. Nothing in a ServiceTitan project is more embarrassing than a finished build waiting on a sandbox.

Credential handling is part of the scope, not an afterthought. Client secret and app key live in a secret store, not in configuration files, and they are rotated on handoff so the operator holds the only live copy. If a vendor cannot describe their key rotation on the diagnosis call, that is worth noticing. There is a fuller list in the security questions to ask before an AI build.

A booking is not a job. In ServiceTitan these are different objects with different lifecycles. A booking is an inbound request that someone converts. A job is scheduled work with an appointment. An AI receptionist that creates bookings and an AI receptionist that creates jobs produce very different mornings for a dispatcher, and the operator needs to choose deliberately rather than inherit whatever the integration defaulted to.

Business unit, job type and campaign are three different dimensions. They get conflated constantly. Capacity and cost roll up by business unit. Work classification is job type. Marketing attribution is campaign. If your AI books everything against a default campaign, you have silently destroyed the attribution the marketing spend is judged on.

Custom fields do not arrive as named properties. They come back as identifier and value pairs, so the layer has to resolve the field definitions before the values mean anything. Build that resolution once, cache it, and refresh it when the tenant adds a field, which they will, without telling you.

Timestamps are UTC and the business is not. Arrival windows, capacity boards and after-hours routing are all local time concepts. Mixing the two produces bugs that only appear near midnight or at a daylight saving boundary, which is exactly when nobody is watching. Normalise once, at the edge, and never let a local time string into the reasoning layer.

Call records and jobs have no native join. Telecom holds the call. JPM holds the job. Tying an inbound call to the job it produced is a matching problem you solve with the number and a time window, and it is the piece most attribution projects underestimate. Getting it right is what makes per-channel reporting possible at all.

None of this is exotic. It is just undocumented in vendor marketing, and it is the difference between a four-week build and a twelve-week one. If the underlying records are messy before you start, read data readiness for mid-market AI first; cleanup happens inside the build, but it has to be scoped.

ServiceTitan enforces rate limits per app and per tenant. Treat a 429 as normal control flow rather than an exception: respect the retry hint, back off, and queue. An AI layer that hammers the API during a nightly sync will get throttled, and the failure mode is a partial dataset the reasoning step happily draws conclusions from. Partial data producing a confident wrong answer is worse than an outage, because nobody notices.

Every write needs an idempotency strategy. Network timeouts happen, retries happen, and a duplicate job means a second truck. Where the API accepts an external identifier, set one deterministically from the source event. Where it does not, check for the record before creating it, and accept that the check plus create is not atomic so the log has to catch the rare double.

Log every call: request, response, latency, and the decision the layer made from it. When an operator asks in month six why the system booked a particular job, the answer has to be retrievable in under a minute. That log is also what tells you when a workflow is ready to graduate from human approval to unattended.

This is the most requested ServiceTitan AI workflow and the one most often wired badly. A voice agent that answers, sounds pleasant, and emails a summary to the office has not integrated with anything. The integration is what happens to the call afterwards.

A correctly wired receptionist does four things against the API. It identifies the caller against CRM customers and locations so a repeat customer is not re-entered as a new record. It reads real dispatch capacity so it only offers arrival windows that exist, rather than promising a slot the board cannot honour. It writes a booking or a job against the correct business unit, job type and campaign. And it hands off to a human on anything it is not confident about, with the partial context attached, rather than guessing.

Capacity is the step that separates a demo from a system. Offering times without reading capacity is how an AI receptionist quietly overbooks a Saturday and turns a technology win into an operational complaint.

On volume: a multi-location home services operator we work with has run 1,486 AI-handled calls and 2,203 minutes on a commissioned voice layer. Across all clients the total is more than 6,000 live calls handled. We are not going to give you a percentage lift, because we do not have a clean measurement of one, and a number invented for a web page is worth nothing to you.

One architectural detail worth borrowing from another vertical. At Jim Glaser Law, a nameable client, the build runs five channel-specific voice agents, one each for PPC, Organic, TV, Meta and LSA, across 3,787 AI-handled calls and 5,514 minutes. Because each channel terminates on its own agent, the firm gets per-channel attribution on answered calls rather than on form fills. The same structure maps onto ServiceTitan cleanly: separate tracking numbers per campaign, an agent per channel, and the campaign written onto the booking at creation. That is per-channel cost per booked job, which is a number most home services platforms currently estimate.

This is the question that makes a PE-backed platform integration different from a single contractor integration, and it has to be answered before anyone writes code.

One tenant, a business unit per brand. One app install, one credential set, one ID space. Cross-brand logic is straightforward because everything is already in the same namespace. The constraints are shared: pricebook, permissions and configuration decisions apply across brands whether or not that suits each brand.

A tenant per brand. Each brand keeps its own configuration and its own autonomy, which is usually why it happened. The integration cost is real: separate app installs, separate permission grants, separate tokens to manage, and record identifiers that collide across tenants. Customer 4471 exists in three brands and is three different people. Any layer reasoning across brands needs its own composite identity from day one.

Neither topology is wrong. What is wrong is discovering which one you have in week three. It changes the identity model, the sync design and the reporting layer, and retrofitting it is the single most expensive mid-build change on this platform.

The related case, common in a roll-up, is a brand that is not on ServiceTitan at all. An acquisition running FieldEdge, Housecall Pro or Workiz will not be migrated for months, and the platform still needs consolidated numbers in the meantime. That is an orchestration problem across systems rather than a ServiceTitan problem, and it is the case where a commissioned layer is most clearly the right answer, because no vendor's native AI reaches outside its own product. The parallel playbooks are FieldEdge AI integration, Housecall Pro AI and Workiz AI integration.

Answer this honestly before commissioning anything, because for a meaningful share of operators the correct answer is to buy what ServiceTitan sells and stop.

ServiceTitan markets AI under the Titan Intelligence brand and sells AI capability inside its Pro product line, including an AI virtual agent for inbound calls. These are real products, they are supported, and they are integrated with the platform in a way no third party can match, because they are inside it. If your requirement is a well-configured version of a workflow ServiceTitan already ships, buying is faster, cheaper and lower risk than commissioning. We will say so on the call.

Where the native products stop is the tenant boundary and the product boundary. They reason about what is inside ServiceTitan, for a customer shaped like the average ServiceTitan customer. Logic that spans separate tenants, or reaches into a second field service system, or encodes a policy specific to one platform's roll-up thesis, is outside what a productised feature can do. That is not a criticism of the product. It is the definition of a product.

The commercial version of this comparison, including pricing shape and speed to value, is on the two pages this playbook deliberately does not duplicate: Pro Services versus commissioned custom AI and ServiceTitan Pro versus a custom build. If you have not decided build or buy yet, start with build, buy or commission.

A note on the word project, because it is overloaded here. In ServiceTitan, a Project is an actual entity in the job management module that groups related jobs, invoices and estimates for larger work. If your requirement is custom reporting or automation across projects, that is a specific integration surface with its own quirks. If you mean a custom development project on top of ServiceTitan, that is this section.

A ServiceTitan commission at ColabContent looks like this. A forty-five minute diagnosis call names one constraint in a sentence. A prototype runs against the operator's real data, in the integration environment, inside seven to ten days, and it either demonstrates the workflow or it does not. If it does, the production build follows on a four to seven week cycle at a fixed fee in the $45,000 to $180,000 band. Integration depth sets the number: a read-only reporting layer at the bottom, bidirectional write-back across several brands and a second field service system at the top.

What the operator holds at handoff: the integration code, the prompts, the model selection, the sync design and the credentials. No retained licence, no recurring platform fee, no dependency on us to keep it running. The reasoning behind that is in why code handoff matters, and the full pricing structure is on the pricing page.

What we do not build on ServiceTitan: a replacement for its CRM, dispatch or invoicing; a second technician mobile app; or a general-purpose chat assistant over the tenant. The leverage is in named workflows with a measurable leak, not in a chat box that does many things adequately.