API development
ServiceTitan Customer & Job Data Integration
Getting customers and jobs out of ServiceTitan is the easy part. Keeping what another system sees correct, minimal and within ServiceTitan's API Terms is the actual work.
Data moves from ServiceTitan through Sync service to Your database.
Why a copy goes wrong
The first version of most data integrations is a nightly export. It works for a few weeks. Then a customer's second property shows up as a new customer, a canceled job still appears on the install board, and two reports disagree by eleven jobs because one ran before a late invoice posted and one after. Nobody trusts the numbers, and the office goes back to looking things up in ServiceTitan.
Syncing customers, locations, jobs and appointments to another application is mostly about the cases nobody plans for: records that change after the fact, records that are deactivated or deleted, one customer with several locations, and the timing between when something happens in ServiceTitan and when the API reports it. Those rules decide whether anyone trusts the tool built on top.
There's also a rule that shapes every design on this page, and it's better to know it before building than after.
Four designs that respect it
Most needs fit one of these. The right one depends on what the tool does with the data, not on what's technically possible.
Read live
The app calls ServiceTitan when someone opens a screen and keeps nothing beyond a short cache. Simplest to defend, limited by rate limits and response time.
Short-lived working copy
A sync service keeps a working set, refreshed continuously and cleared on a schedule within the permitted window. Fast screens without a growing archive.
Keep only what's needed
The app stores its own data, such as checklists, notes and follow-up status, keyed to ServiceTitan IDs, and pulls the details from ServiceTitan as needed. What may be kept is confirmed first.
Longer retention, where allowed
History tables or a reporting store only where ServiceTitan's documentation or written permission covers that use for your account, confirmed before building.
How a sync service works
ServiceTitan offers two styles of API: transactional calls that page through lists, and export feeds for bulk and incremental sync. See <a href="https://developer.servicetitan.io/docs/getting-started/transactional-and-export-api" rel="noopener" target="_blank">transactional and export APIs</a>.
- 1
Initial load from the export feed
Customers, locations, contacts, jobs and appointments each have export feeds. The first run reads from the beginning and stores a continuation token when it finishes.
- 2
Incremental runs from the continuation token
Each later run passes the saved token and receives only what changed since. The token is saved after each successful batch, so a failed run picks up where it stopped instead of starting over.
- 3
Handle active, inactive and deleted records
Export feeds return inactive and deleted records as well as active ones. The sync marks or removes them so a deleted appointment disappears from the crew calendar.
- 4
Allow for timing
Changes generally appear in export feeds after about 15 minutes. An option returns recent changes sooner but may include duplicates, so the sync updates by ServiceTitan ID rather than inserting blindly.
- 5
Map IDs and apply conflict rules
Every stored record keeps its ServiceTitan ID. ServiceTitan is the source of record for its own fields; the app owns only the fields it adds, so nothing gets overwritten in either direction by accident.
- 6
Reconcile and report
A regular check compares counts and recent records against ServiceTitan and alerts someone when they disagree, before a report goes out wrong.
Details that keep the data honest
Customers vs locations
One customer can have several service locations, and jobs belong to a location. Designs that collapse the two produce the duplicate-customer problem.
Rate limits
ServiceTitan's documented default is 600 calls per 10 seconds per application per tenant, for all APIs except reporting. The integration spaces its calls and backs off and retries when ServiceTitan throttles requests. See ServiceTitan's rate limit FAQ.
Change detection
Export feeds are the main incremental tool. Where a resource has no feed, the integration checks for changes on a schedule using whatever filtering that resource supports, confirmed during scoping.
Errors and retries
Failed batches are retried with backoff, logged with the record IDs involved, and escalated to a person if they keep failing.
Data minimization
Only the fields the tool uses are requested and stored. A crew calendar doesn't need customer email addresses.
Who can see it
Content about a customer is only shown to the people who need it, and never to other customers or outside parties.
ServiceTitan's own exports vs a sync service
| Need | In ServiceTitan | Custom-built |
|---|---|---|
| Getting data out | Reports can be run, exported as PDF or XLSX, and scheduled inside ServiceTitan. | A sync service reads the APIs directly and keeps the target app current without anyone exporting files. |
| Freshness | As fresh as the last export or scheduled report. | Usually within minutes of a change, depending on the feed and the sync schedule. |
| Deletes and changes | Each export is a new snapshot; spotting what changed is manual. | Inactive and deleted records are handled automatically by ServiceTitan ID. |
Where sync shows up by trade
HVAC
Install and maintenance appointments synced to a crew calendar app that also tracks equipment delivery.
Plumbing
Jobs and locations feeding a permit and inspection tracker, with deleted jobs removed automatically.
Multi-trade
Customers and jobs from several business units feeding one coordination app, grouped by the division each job belongs to.
Where this connects
Sync is a building block, not usually the end product. It feeds custom ServiceTitan applications and, for reporting, custom dashboards. Estimates and invoices have their own validation concerns, covered on estimates and invoice integrations. The work follows the same practices as our general API integration projects, and the overview is on ServiceTitan API development.
What to have ready before we talk
None of this is required for a first call, but each answer makes the scope and the quote sharper.
- Which records the target app needs: customers, locations, contacts, jobs, appointments
- How fresh the data has to be for the people using it
- What the app will add of its own, and what it only displays
- How long any ServiceTitan data needs to stay, and why
- Where the target database or app is hosted, and who can see it
- How deleted or canceled records should look in the app
Related ServiceTitan development
Mesa Web Designers is an independent developer. We are not affiliated with, endorsed by, or a partner of ServiceTitan. ServiceTitan is a trademark of its owner. What an integration can do depends on your ServiceTitan products, the permissions your admin grants, and the APIs available to your account.
Start the conversation
Plan a sync you can trust.
Tell us which records another app needs and how fresh they have to be. We'll propose a design that fits the API Terms and your team's needs.
- Web apps, portals and integrations start from $575, priced by complexity
- The developer who scopes it builds it and answers the phone
- Built for ServiceTitan contractors nationwide
What do you need built?
Pick what fits (pick any)
Rather talk? (480) 525-7582. 0% financing on any project, 25% down. See all pricing
Customer & job data sync: questions we hear a lot.
How quickly do ServiceTitan changes reach the synced app?
Changes generally appear in ServiceTitan's export feeds after about 15 minutes. An option returns recent changes sooner but may include duplicates, which the sync handles by updating records by ID.
Can we keep a permanent copy of our ServiceTitan data in our own database?
Not as a default. ServiceTitan's API Terms limit storing API content beyond 24 hours unless the Terms or documentation permit it. We design for keeping only what's needed and refreshing it, and confirm any longer retention with ServiceTitan before building.
What happens when a job is deleted in ServiceTitan?
Export feeds return deleted and inactive records along with active ones, so the sync can remove or flag the record in the target app on its next run.
Will syncing slow down ServiceTitan for our team?
It shouldn't. The integration stays within ServiceTitan's documented rate limit of 600 calls per 10 seconds per application per tenant, spaces its requests, and backs off if ServiceTitan throttles it.
Plan a sync you can trust.
Tell us which records another app needs and how fresh they have to be. We'll propose a design that fits the API Terms and your team's needs.