How to Integrate ServiceTitan With Custom Software

Build custom, use ServiceTitan, or both?

For most residential HVAC, plumbing and electrical contractors, ServiceTitan covers dispatch, the technician mobile app, estimates, memberships, payments and reporting well enough that replacing it makes little sense. The real question is usually narrower: one workflow ServiceTitan handles awkwardly, or one system it does not talk to. Tepia’s first step is naming that workflow precisely.

Common examples include a branded customer app for booking and membership details, a commercial portal where facility managers see every job across their sites, sync to an ERP such as NetSuite or Sage Intacct, a reporting warehouse that combines several brands after an acquisition, or a specialized tool for work like commissioning large equipment. Each of these can sit on top of ServiceTitan through its APIs instead of replacing it. If you are weighing a full move away, read ServiceTitan alternatives first.

Step by step: integrating ServiceTitan with custom software

1. Define the workflow and its data. Write down which ServiceTitan records the custom software reads, which it writes, and how fresh each one must be.
2. Get API access. Register an application in ServiceTitan’s developer portal, then have an admin in the contractor’s account enable it for their tenant and share the tenant ID and client credentials through a secure channel.
3. Map entities. Match ServiceTitan customers, locations, jobs, appointments, technicians, estimates and memberships to your app’s model, including which business units and job types apply.
4. Design the middleware. Place a service between ServiceTitan and your app to handle OAuth token refresh, throttling, retries and logging, rather than calling the API from a phone or browser.
5. Choose sync patterns. Poll for records modified since the last successful run, use webhooks where they exist for the events you need, and keep full reloads for nightly reconciliation.
6. Handle writes carefully. Writes such as booking a job or adding a note should be idempotent and validated against ServiceTitan’s rules, with clear errors shown to the user.
7. Test real scenarios. Cover rescheduled appointments, merged customers, canceled jobs, several locations per customer and technicians who work across business units.
8. Monitor after launch. Track API errors, sync lag and record counts, and alert someone before a dispatcher notices a missing job.

Tepia builds steps four through eight as shared infrastructure, so adding a second workflow later is mostly mapping work.

Common integration goals and the ServiceTitan data behind them

Most contractors start with one of these goals. Tepia uses this table in Discovery to agree on direction and freshness for each.

Whichever row you start with, Tepia designs the middleware so the next row reuses the same authentication, logging and mapping code.

Engineering details that keep the integration reliable

ServiceTitan integrations break in predictable ways, so Tepia designs for each one up front. Access tokens expire, so the middleware refreshes them automatically. API requests are rate limited, so syncs use change based queries and queues instead of reloading every job. Large tenants hold years of history, so the first backfill runs in batches outside business hours.

• Store ServiceTitan IDs on every record in your app so updates and deletes match exactly.
• Keep a sync cursor per entity and advance it only after a batch succeeds.
• Treat ServiceTitan as the source of truth for anything that appears on a customer’s billing record.
• Log each request and response with a correlation ID, and keep logs long enough to investigate disputes.
• Run a nightly reconciliation of counts by day and business unit, and alert on mismatches.

Credentials stay server side in AWS Secrets Manager or Azure Key Vault, never inside a mobile app, and Tepia requests only the API access the workflow needs. More on these patterns is on our ServiceTitan integration development page.

How Tepia approaches ServiceTitan integration

Each ServiceTitan project follows Tepia’s six phases with a US based project manager.

1. Discovery: workflow interviews with dispatch, office and field teams, a review of your ServiceTitan setup, business units and job types, and confirmation of API access. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a facility manager downloading every service report for one site.
2. Design: an entity mapping document, sync and error handling design, and wireframes of the custom app or portal screens.
3. Development and Testing: an Alpha against a limited set of real records, then a Beta with one branch or business unit, with test plans for sync accuracy, write validation, permissions and load.
4. Training: sessions for office staff on how the custom app and ServiceTitan relate, and on reading the sync status screen.
5. Launch: backfill of history, staged activation of writes and support reps watching sync logs through the first weeks.
6. Support: monitoring, issue resolution, updates when ServiceTitan changes its APIs, and new workflows as feature requests.

The usual pattern is 1 to 3 months of Discovery, 2 to 6 months of development and QA, and around a month to launch, with single workflow integrations near the short end. See our process, our field service customer portal work, or talk to Tepia about your ServiceTitan setup.

Frequently asked questions