ServiceTitan API: what a real integration involves
OAuth2 client credentials, a second app-key header, and an admin at every tenant who has to click connect before any of it works.
Answered in short
5 things that decide this
- 01ServiceTitan's API requires a registered developer app and OAuth2 client-credentials auth plus a separate ST-App-Key header. It also requires per-tenant approval from that customer's own admin before a single call succeeds.
- 02You cannot build on a client's own App Key. ServiceTitan calls that tunneling and bans it outright, so an agency has to be its own registered dev shop.
- 03Rate limits are generous once connected: 600 calls per 10 seconds per app per tenant, and 5 runs of the same report per minute per tenant on the reporting endpoints.
- 04The common integrations are booking write-back, job and customer sync to QuickBooks, call-recording links on the job, and custom reporting pulls. Marketplace listing needs a Partner Program agreement and a security review on top.
- 05This page sets out the access model as ServiceTitan documents it, and how we'd approach a build against it. Every tenant's module mix and approved scopes differ, so we confirm what your own account exposes during the audit, before any of this gets scoped.
The gate is people, not code
Most field-service platforms hand you an API key and a docs page. ServiceTitan hands you a queue. There's no self-serve signup. Your own ServiceTitan admin has to set you up as a user in their test environment, or ServiceTitan checks your request and sends credentials directly. Either way, someone on the other side has to say yes before you write a line of code against it.
Once your app exists, it still doesn't work for anyone. Each customer's tenant admin has to open their own ServiceTitan settings, connect your app, and approve its scopes. Until they do, the app sits at "Not Connected Yet," and there's no way around that from your side. Credentials are per tenant too. Every shop you connect gets its own client ID and secret pair, not a shared key that works across accounts.
So the real question before you scope any ServiceTitan work isn't whether the API can do what you need. It's whether you're set up as your own registered developer. And it's whether the customer's admin is free to click connect and approve scopes, maybe more than once as the app changes.
Five gates, in the order you hit them
ServiceTitan's own developer portal lays this out plainly once you're inside it. Getting inside is the trick.
- 01No self-serve account. Access is requested and verified, not signed up for. Budget calendar time here, not engineering time.
- 02Two ServiceTitan-side permissions gate app registration on the tenant: Generate API Application Key and Manage API Application Access. A customer's admin needs both before anything moves.
- 03Per-tenant admin approval. The customer connects your app and approves its scopes inside their own account. There's no bulk approval and no way to skip a tenant.
- 04Credentials are per tenant, always. A rollup with twelve locations on twelve ServiceTitan instances means twelve client ID and secret pairs to issue, store and rotate.
- 05Scope changes require re-approval by every tenant that already connected. Ship a new version of your app that asks for one more field, and every admin has to click Upgrade to New Version again.
- Register the appOur own developer org, our own integration environment
- Tenant admin connectsTheir ServiceTitan settings, their decision
- Scopes approvedPer tenant, re-approved on every version bump
- Booking Provider Tag setA non-technical admin creates it, or bookings fail silently
- Auth and callsOAuth2 client credentials plus ST-App-Key header
Skip a step here and the app sits at "Not Connected Yet" with no error to debug — it's a person, not a bug.
What actually goes over the wire
Authentication is OAuth2 client-credentials, but every call also carries a separate ST-App-Key header. Two independent secrets, not one bearer token doing double duty. Rate limits, once you're through the gates above, are workable. Standard endpoints get 600 calls per 10 seconds per app per tenant. Reporting is tighter, at 5 calls per minute per tenant, since those queries are heavier for ServiceTitan's own systems to run.
Webhooks exist and are enabled per app, which matters for anything that needs to react to a job status change rather than poll for it. One gotcha trips up a lot of first integrations. The tenant has to pre-configure a Booking Provider Tag in their own settings first. Then they select it when they connect your app. Miss that step and bookings fail with no obvious error. It looks like a bug in your code when it's actually a setting nobody set.
Listing on the ServiceTitan Marketplace is a separate track from having API access at all. It needs the Partner Program, an information-security review, and a signed agreement. A shop-specific integration that only that shop ever uses doesn't need any of that. A packaged product other shops install does.
The integrations shops ask for, and what each one involves
Most requests fall into a handful of shapes. None of them is harder than the access model above, but each has its own way of breaking.
- 01Booking write-back: an outside system, usually a voice agent or web form, creates a job on the tenant's dispatch board with the right customer match, job type, urgency tag and technician capacity check. This is what "books into ServiceTitan" actually means when a vendor says it.
- 02Job and customer sync to QuickBooks: revenue, job costing and customer records moving between ServiceTitan and QuickBooks Online or Desktop, so the office isn't re-keying invoices by hand.
- 03Call-recording links: the recording and transcript from a phone call or voice agent attached to the job it produced, so a technician or the office can hear exactly what the customer said.
- 04Custom reporting pulls: job, revenue or technician data pulled out on a schedule for dashboards ServiceTitan's own reporting doesn't build, respecting the tighter 5-per-minute limit on those endpoints.
- 05Zapier versus a direct build: Zapier's ServiceTitan connector covers a handful of common triggers and actions with no code, which is the right call for a simple one-way sync. A direct build earns its cost once the write-back needs capacity checks, custom tagging or logic Zapier's prebuilt steps don't cover.
The failure modes worth asking about before you sign anything
A ServiceTitan integration that works in a demo and breaks in production usually fails in one of four familiar ways.
- 01Capacity ignored: a booking lands on the board for a slot that looks open but isn't, because the integration checked the calendar grid instead of live technician skill, licence class and truck stock.
- 02Duplicate customers: a caller's name doesn't match cleanly against the existing account, so the write-back creates a second customer record instead of matching the first. Dispatch ends up with two histories for one household.
- 03Auth expiry: OAuth2 tokens and refresh cycles expire on a schedule. Store the wrong token, or miss a rotation, and the integration works for weeks before it silently stops writing anything at all.
- 04Scope drift: an app update adds a field or a permission, every connected tenant needs to re-approve it, and a shop that misses that notification finds its integration quietly broken until someone reconnects it by hand.
Some of the systems we have shipped
Related questions
01Can I get ServiceTitan API access on my own, without an agency?+
Yes, if you register as your own developer and go through ServiceTitan's checks. Most shops don't have the engineering time for that on top of running the integration afterward, which is why they bring in a partner. Either path goes through the same gates.
02Does ServiceTitan charge extra for API access?+
ServiceTitan doesn't publish a fee or a required plan tier for developer access in its own docs. Treat any specific figure a vendor quotes as a claim to check against your own account, not a published fact.
03How long does approval actually take?+
ServiceTitan doesn't publish a service-level timeline, and it depends on your own admin's availability as much as ServiceTitan's review. Plan the access request as a calendar-time task with lead time, not something you can start the same week you want to launch.
04Is Housecall Pro or Jobber easier to integrate than ServiceTitan?+
Jobber is the cleanest of the field-service platforms to build against: GraphQL, OAuth2, and private integrations serving five or fewer accounts skip review entirely. Housecall Pro has a public API surface but ServiceTitan-level detail on auth and limits isn't published. ServiceTitan is the most gated of the three, and the gating is about approvals, not code.
05What does Hashlogics actually do on a ServiceTitan project?+
We start by confirming exactly what your tenant exposes, what's already approved, and what a write-back needs to respect. That happens during the audit, against your own account, not against the general docs. The build gets scoped from what we find there.
Related
- ServiceTitan Contact Center vs custom voice AI →The built-in add-on against a custom build, side by side.
- How to automate HVAC dispatch with AI →What the automation does once the booking lands on the board.
- HVAC dispatch automation →What we build around the platform you already run.
- HVAC business software →The custom layer where the platform genuinely can't do the job.
- HVAC software development →What we build for HVAC operations.
- Missed-call cost calculator →Put your own call volume against the math.
