What ServiceTitan's API gives you, how each record maps onto Payaca, and what we learned running a full ServiceTitan migration for a US electrical and solar contractor.
Most teams who ask us about leaving ServiceTitan have already made the decision, and what they want to know is how much of a decade of jobs, customers and invoices actually comes with them. This guide answers that from a migration we've run end to end, through the ServiceTitan API with access the customer enabled on their own account.
Short version: the operational record moves cleanly. Customers, contacts, locations, jobs, tags, equipment, notes and upcoming appointments all come across. Historical financials are a decision, not a default, and photos and attachments need their own plan. Get those two decisions made early and the rest is mechanical.
Want us to look at your account?
Book a migration walkthrough and we'll map your ServiceTitan setup to a Payaca account: business units, job types, statuses and what you need to keep from the history.
Solar, battery, EV charger and electrical businesses running install projects on ServiceTitan, usually with a service arm alongside. If most of your revenue comes from multi-stage install projects (survey, design, permit, install, inspection, interconnection) and the service side is the smaller part, this is the move we're describing. If you run a large call center and dispatch operation where service calls are the business, ServiceTitan is built for that and this guide probably isn't for you.
ServiceTitan's API is split into modules, and its public reference lists them: CRM (customers, contacts, locations, leads, bookings, tags), Job Planning and Management (jobs, appointments, projects, job types, project statuses, job and project notes), Accounting (invoices, payments, GL accounts, tax zones), Pricebook (services, materials, equipment, categories), Equipment Systems (installed equipment), Memberships, Marketing (campaigns), Dispatch, Payroll, Inventory, Forms and Settings (business units, employees, technicians, tag types).
For a full extract, the useful part is ServiceTitan's Data Export APIs. These have /export in the path, return active, inactive and deleted records with no filters, and page through with a continuation token rather than page numbers. On the account we moved, export feeds were available for customers, jobs, invoices, invoice items, payments, estimates, appointments and calls. Everything else comes from the standard list endpoints.
Before pulling anything, we ran a read-only sizing pass: one call per entity to read its total count, no data. That told us what was actually populated. On this account it was roughly:
Two things the API doesn't give you in bulk. Photos and attachments have no bulk endpoint, so site photos, signed PDFs and permit documents attached to jobs need a separate plan. Notes are only available per record (per customer, location, job or project), so they come across, but one call at a time.
The model in one paragraph
In ServiceTitan, a customer has locations and contacts, and jobs hang off a location. In Payaca, a Customer has Customer Contacts and Addresses, and a Project is the unit of work, linked to the customer and its site address. Each ServiceTitan job becomes a Payaca project. Projects sit in a pipeline and move through its stages.
Record by record, this is how we mapped it:
The financial history is the one that needs a real conversation. There are four sensible ways to handle it:
The question we ask is simple: when you need an old invoice, do you open ServiceTitan or QuickBooks? For most businesses it's QuickBooks, and the answer is a mix of the first three.
Scope first. The sizing pass gave us the counts, and from them a list of decisions for the customer: how many years of history to bring across, whether call history was in scope, and which photos and attachments mattered.
Set up the account before loading anything. We built their setup in a test account first, then in their live Payaca account: pipelines from the business units, the custom fieldsets (ServiceTitan ID, lead source, equipment and their solar fields), and a map from every ServiceTitan status to a Payaca stage.
Load in dependency order. Pipelines and fieldsets, then customers with their contacts and addresses, then projects with their tags, custom fields and stages, then notes, then the financial summary. Each layer depends on the one before it existing.
Check the counts. After each layer we compared what landed in Payaca against the totals ServiceTitan reported, and spot-checked individual customers end to end. A customer's jobs, notes and totals should match what the office sees in ServiceTitan.
Dry run, then cut over. A full dry run before the real load, then the cutover itself, then a period of close support while the team settled in. We ran it as a phased rollout around the team's own bandwidth rather than over one weekend, starting with the department that leaned on ServiceTitan hardest.
A US electrical and solar contractor with around 17,000 customers, 20,000 jobs and a decade of history across four business units moved over this way. Their customers, jobs, equipment and notes came across into Payaca, with each job landing as a project in the pipeline for its business unit.
The employee count isn't your seat count. ServiceTitan showed over 200 active employees on this account. Once we filtered out placeholder and system records, there were about a dozen real office users plus the active technicians. Confirm who actually logs in before you size anything.
Check where the history really starts. ServiceTitan accounts sometimes carry older data imported at setup, so the first record can predate the business's real use of the system. Look at when jobs actually start before deciding how many years to bring.
Tidy business units before you import, not after. They become pipelines, and pipelines are much easier to get right on day one than to merge later.
Solar system specs may not be in ServiceTitan. Installed equipment on this account was mostly electrical, with thin solar detail. The array, inverter and production data usually lives in your design tool or inverter monitoring. Plan to bring that across from there.
Some features are switched off by plan. The top-level contacts list wasn't available on this account, so contacts came through each customer record instead. Same data, different route.
Unused features are fine. ServiceTitan custom fields were empty here, and the memberships program had wound down years earlier with none active. That's less to map, not a gap. Check yours, but don't assume they're full.
Photos are the wildcard. Decide early which ones matter (signed contracts and permits usually do, every site photo usually doesn't) and keep the rest as an archive.
If you're running install projects on ServiceTitan and wondering what your data would look like in Payaca, book a walkthrough. We'll go through your business units, job types and statuses, show you where each one lands, and talk through what you want to keep from the history. You'll leave with a clear list of decisions, whatever you decide to do next.
ServiceTitan is a trademark of its owner. Payaca isn't affiliated with or endorsed by ServiceTitan.
See how Payaca helps clean tech installers save time and grow their business.
Request a demoWant more from Payaca in your Google results?
What came across, and what we rebuilt, when a US solar and electrical contractor moved its solar business off Scoop, with Zoho on the sales side, and onto Payaca. Written from the migration we ran.
US solar installers don't have one national permitting clock - they have as many as they have AHJs. Here's what that variance actually costs a growing install business, backed by NREL data.
Mid-sized US solar and clean-energy installers spend two engineers a year keeping a bespoke CRM alive that handles maybe 60% of the workflow. Permits, AHJ inspections, NEM interconnection and incentives end up on spreadsheets. The real cost of the build, and what the off-ramp usually looks like.
