ServiceTitan has one of the deepest, most open APIs in field service — 20+ modules spanning the entire home-services lifecycle, lead to payment. Nearly the whole operation is reachable, any customer can authorize a third-party app on their tenant, and an AI agent can run a full intake-to-booked-job workflow end to end. The one real soft spot is eventing: webhook coverage is partial and reporting is throttled, so you sync by polling, not push.
The definitive developer's guide to running an AI agent inside a ServiceTitan workflow — the auth model, the full API surface with real endpoints, rate limits, change capture, the booking write-path, and the gotchas. For home-service businesses on ServiceTitan, an agent can use the APIs the way your staff use the software: answer the call, qualify, update the contact, find a real open slot, and book the job onto your dispatch board without anyone re-typing a thing.
We wrote this having built one end to end (see the Ella case study). Endpoint paths and limits below reflect ServiceTitan's public developer docs — always confirm current specifics against developer.servicetitan.io.
ServiceTitan uses OAuth 2.0 client-credentials — machine-to-machine, no user login flow. The nuance that trips people up: access is split between you and the customer, and every request carries two credentials.
In ServiceTitan's Developer Portal you create an integration app: choose API scopes and webhook events, set callback URLs, and generate an app key. The app key identifies your application on every request.
A tenant admin generates a client ID + secret under Settings → Integrations → API Application Access (separate credentials per environment) and connects your app. There's no blanket platform access — it's per tenant, scoped, and revocable.
POST the client ID + secret with grant_type=client_credentials to the auth host. You get a short-lived (~15-minute) bearer token — no refresh tokens, so cache it and re-request when it expires.
Authorization: Bearer <token> proves you're authorized on the tenant; ST-App-Key: <app key> identifies your app. Both are required — drop either and the call fails.
Integration (sandbox) uses the -integration hosts; Production uses api.servicetitan.io with credentials the customer's admin generates.
Every tenant-scoped call follows one pattern — /{module}/v2/tenant/{tenant}/{resource}. These are the modules an agent draws on:
| Module | Path | Key resources |
|---|---|---|
| CRM | crm/v2 | Customers, contacts, locations, leads, bookings, tags |
| Jobs (JPM) | jpm/v2 | Jobs, job types, appointments, projects, hold / cancel reasons, history |
| Dispatch | dispatch/v2 | Capacity, arrival windows, zones, technician shifts / skills, non-job appointments, business hours |
| Pricebook | pricebook/v2 | Services, materials, equipment, categories, discounts & fees, client pricing |
| Sales & Estimates | sales/v2 | Estimates, estimate items, proposal templates |
| Accounting | accounting/v2 | Invoices, payments, payment terms/types, GL accounts, journal entries, tax zones |
| Memberships | memberships/v2 | Membership types, customer memberships, recurring services & events |
| Marketing | marketing/v2 | Campaigns, categories, costs, attribution |
| Settings | settings/v2 | Business units, employees, technicians, tag types, user roles |
| Telecom | telecom/v2 | Calls, call detail, recordings |
| Inventory | inventory/v2 | Purchase orders, receipts, returns, transfers, vendors, warehouses, trucks |
| Equipment Systems | equipmentsystems/v2 | Installed equipment & equipment systems |
Also exposed: Forms, Reporting, Payroll, Timesheets, Task Management, Service Agreements, Scheduling Pro, Marketing Ads & Reputation, Findings.
| Area | What the agent does | Access |
|---|---|---|
| CRM | Look up a caller by phone; create customers, contacts, and service locations; create bookings | Read · Write |
| Jobs (JPM) | Read the job-type catalog; create, schedule, cancel, hold, and reschedule jobs & appointments | Read · Write |
| Dispatch | Read real capacity, zones, and arrival windows; assign technicians; place appointments | Read · Write |
| Estimates & pricebook | Pull pricebook items; build and send estimates; chase open ones | Read · Write |
| Invoices & payments | Read balance status; record payments; follow up on open balances | Read · Write |
| Memberships | Read membership status; renew recurring services | Read · Write |
| Telecom | Read calls and recordings — drive call-based intake and QA | Read |
| Marketing | Read campaigns and attribution — book with the right lead source | Read |
| Settings | Business units, technicians, tag types — so it books to your real config | Read |
A booked job isn't one write — it's a short, ordered chain: read the tenant's config, resolve or create the customer and their service location, then create the job with a real appointment. The IDs in bold are tenant-specific foreign keys you must resolve first — they can't be hard-coded.
This is ServiceTitan's honest weak spot for AI — and knowing it up front saves you an architecture rewrite. Real-time is limited; you sync by polling.
List endpoints take page and pageSize (up to 5000) and filters like modifiedOnOrAfter / createdOnOrAfter. Polling by "what changed since my last cursor" is the bread-and-butter sync pattern.
For real incremental sync, ServiceTitan's Export endpoints return a durable continueFrom token — store it and pass it back to pull only new and changed records. It's the reliable backbone for a knowledge/analytics sync.
V2 webhooks are HMAC-signed and configured per app, but coverage is a subset of entities (think jobs, appointments, customers) — not the whole surface. Treat them as best-effort triggers and keep polling as your source of truth.
Each ServiceTitan customer installs your app and grants scopes. You authenticate per tenant with their client ID/secret plus your app key. Adding scopes or webhook events later publishes a new app version the tenant admin must re-approve — so plan your scopes up front.
You cannot hard-code IDs. Booking a job means first reading that tenant's business units, job types, campaigns, and often pricebook items — they're required foreign keys and differ per customer. Onboarding a new tenant means a discovery-and-mapping step.
The API won't dedupe for you, and there's no general idempotency key — a retry can double-create. Match on phone and address first and only POST when there's genuinely no match. Read-before-write is mandatory for an autonomous agent.
For new inbound work, POST to the CRM Bookings endpoint (optionally via a registered Booking Provider) rather than creating a raw job — it lands in ServiceTitan's booking queue with the tenant's own validation and dispatch rules, which is the lower-risk write path.
Webhook coverage is partial, exported changes surface on a short delay, and reporting is throttled hard. An agent that needs instant, full-surface awareness must poll and accept some lag — architect for it rather than assuming real-time events.
Roughly 60 requests/sec per app per tenant (reporting far stricter). It scales per tenant, but bulk or backfill work must batch and cache; naive fan-out will hit 429s — back off exponentially.
Anything the API doesn't expose, or that you'd rather not automate, routes to a person. A good agent knows its boundaries and hands off instead of guessing.
Our end-to-end intake AI for a multi-state plumbing client on ServiceTitan. Answers every call, qualifies the job, checks whether it's an existing or new contact, extracts a structured record, and creates and books the job end to end — down to the exact API calls.
Read the case study →Whether you're building it yourself or want a done-for-you solution, we can help.