How do I get API access to my ServiceTitan data?

Access is requested, not just switched on

Getting to the API is an administrative process before it is a technical one. Someone registers an integration application, declares which data it needs, and then an administrator inside your tenant approves that application against your specific account. Until that approval happens, correct code with correct credentials still returns nothing useful.

Plan for that approval step to take real calendar time. It is the single most common reason a systems integration project slips in its first week, and it is entirely outside the engineering team's control.

What the credentials actually consist of

You will end up holding a small set of values, and it helps to know what each one does before someone emails them around in plain text.

• Client ID and client secret. These identify the application and are exchanged for a short-lived access token. The token expires; the integration has to refresh it automatically rather than storing one and hoping.
• App key. Sent alongside the token on each request to identify the application making the call.
• Tenant ID. Identifies your specific ServiceTitan account, and appears in nearly every endpoint path. Multi-tenant operators have one per tenant.
• Environment. There is a separate non-production environment. Build and test against it, because a write-capable integration pointed at live dispatch data is a bad way to learn.

Scope narrowly the first time

Ask for read access to the specific areas the project needs — jobs, invoices, customers, calls — rather than everything available. Narrow scopes are faster to justify internally, and they mean an integration that goes wrong cannot go wrong in an area it was never supposed to touch.

Register a separate application per integration rather than sharing one set of credentials across a reporting pipeline, a marketing sync and a dashboard. When one vendor relationship ends, you revoke one application instead of rotating credentials for everything at once.

Own your own keys

The contractor should own the credentials. Vendors should be given their own registered application under your tenant, not a copy of yours. This matters at the least convenient moment — when you change vendors — because the alternative is discovering that your data pipeline lives inside somebody else's account.

Document what each application does, who owns it and what it reads. That document is worth more than it looks on the day someone asks why an unfamiliar system is pulling your invoice data. The same discipline applies to every API connection in the business.