API development
ServiceTitan API Authentication & Integration Setup
Access to the ServiceTitan API is granted by your company, not taken by a developer. This is how the app, the keys, the token and the permissions fit together, and who does each step.
Diagram: the contractor's ServiceTitan tenant grants an app access. A server-side integration layer requests an access token, calls the permitted APIs, stores what it needs in its own database, and feeds the custom application.
Four identifiers, three owners
A ServiceTitan integration carries four pieces of identity, and most setup confusion comes from mixing them up.
The app key identifies the application. It's generated when the app is registered in ServiceTitan's Developer Portal and stays the same from testing to production. The client ID and client secret identify the application's connection to one specific ServiceTitan account in one environment. They're generated only after a tenant admin approves the app. The tenant ID identifies your ServiceTitan account and appears in the path of every API call. The access token is what the integration exchanges the client ID and secret for, and it expires after 15 minutes.
The developer owns the app registration. Your admin owns the approval and the client credentials it produces. ServiceTitan owns the process connecting the two. This page follows ServiceTitan's developer documentation; where something depends on your account, it says so. For how this fits the rest of a project, see ServiceTitan API development.
Setting up access, in order
- 1
Check with ServiceTitan's integrations team
ServiceTitan advises customers to contact it at integrations@servicetitan.com before engaging an outside developer, and not to give third parties admin rights or the permission to generate API application keys. We ask clients to do the same before any work starts.
- 2
Register the app in the Developer Portal
The developer registers the application under My Apps and requests scopes: read and/or write, per resource. Saving the registration generates the app key. Changing the scopes later creates a new app version.
- 3
Your admin reviews and approves
A tenant admin with the Manage API Application Access permission connects the app in Settings > Integrations > API Application Access, reviews the scopes it requests, and allows or declines it. Approval generates the client ID and client secret.
- 4
Credentials go to the server
The client ID and secret are entered directly into the integration's secret storage by your admin or through a secure handoff. They never travel by email, chat or a shared document.
- 5
Build and test in the integration environment
Development uses ServiceTitan's integration environment, its sandbox, with its own base URL, token endpoint and credentials. ServiceTitan offers ways to have production data copied into it for testing.
- 6
Go live
Production uses the same app key with the production tenant's client ID and secret, so going live is a configuration change on the server, not a rewrite.
How the token works
ServiceTitan's V2 APIs use the OAuth 2.0 client credentials flow, which is designed for machine-to-machine access. There's no user login and no refresh token. The integration sends its client ID and secret to the token endpoint for its environment and receives an access token that lasts 15 minutes. When it expires, the integration simply requests a new one with the same credentials. See ServiceTitan's OAuth 2.0 documentation.
Tokens should be cached and reused until shortly before they expire. ServiceTitan throttles requests for new tokens, so an integration that asks for a fresh one on every call will eventually be refused. A well-built integration layer keeps one token per environment and tenant, renews it on a timer or on expiry, and retries a call once with a new token if the old one is rejected.
Every API call then carries two things in its headers: the access token in the Authorization header, and the app key in the ST-App-Key header. The tenant ID is part of the request path. Production and integration have separate base URLs and token endpoints, so the environment is a setting, never something hard-coded.
Scopes: ask for the least that works
Scopes are granted per resource, separately for reading and writing. Your admin sees exactly what the app asks for, and so should you.
A reporting dashboard
For example, read access to jobs, invoices and business units, and no write scopes at all.
A website booking flow
Write access to create bookings, plus whatever read access it needs to choose a campaign or business unit. Not write access to jobs.
An estimate follow-up tool
Read access to estimates and customers. Write access only if it must record a status back, and only for that resource.
Changing scopes later
Adding a scope creates a new app version that your admin reviews and approves again. That's a feature: nothing gains access quietly.
Storing and rotating secrets
Server-side only
The client secret and app key live in the server's secret storage or environment configuration. They never appear in browser code, a mobile app, a public repository or a log file.
Separate per environment
Integration and production credentials are stored separately and named clearly, so a test run can't touch live data by accident.
Rotation
Rotate when someone with access leaves, when a secret may have been exposed, or on a schedule you set. The exact steps follow ServiceTitan's process for your account, which we confirm during setup; the integration is built so a new secret is a configuration change.
Turning it off
Your admin can review or remove the app's access in ServiceTitan's API Application Access settings. The handover documentation says what stops working if they do.
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.
- Who your ServiceTitan admin is, and whether they have the Manage API Application Access permission
- Whether you've contacted ServiceTitan's integrations team about this project
- The resources the integration needs, and which of them it must write to
- Whether your account has an integration environment, and whether production data should be copied into it
- Where the integration will be hosted and how secrets will be stored
- Any apps already connected to your account, and what they can access
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
Get the setup right the first time.
We'll walk your admin through registration, scopes and approval, and set up credential storage and token handling on the server.
- 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
API authentication & setup: questions we hear a lot.
How long does a ServiceTitan access token last?
Fifteen minutes. The client credentials flow has no refresh token, so the integration requests a new access token with its client ID and secret when the old one expires. Tokens should be cached, because ServiceTitan throttles requests for new ones.
What's the difference between the app key and the client secret?
The app key identifies the application and is sent in the ST-App-Key header on every call; it stays the same in testing and production. The client ID and secret are created when your admin approves the app for your account, are specific to an environment, and are used to get access tokens.
Who has to approve the integration?
A ServiceTitan admin in your company with the Manage API Application Access permission. They review the scopes the app requests and allow or decline it in Settings > Integrations > API Application Access.
Can we just give the developer a ServiceTitan login instead?
No. ServiceTitan advises against giving third parties admin rights and prohibits workarounds where a developer creates users or apps inside a customer's account. Approved API credentials are the correct and safer route.
Do we have to test in production?
No. ServiceTitan provides a separate integration environment with its own credentials, and production data can be copied into it. Going live keeps the same app key and switches to the production tenant's client ID and secret.
Get the setup right the first time.
We'll walk your admin through registration, scopes and approval, and set up credential storage and token handling on the server.