Docs/Integrations

ServiceTitan

What to set up in ServiceTitan, the four credentials and how they are checked, the nightly import of payments, and what the card shows.

Connect ServiceTitan with credentials from your own ServiceTitan account, and the payments recorded there are imported every night and matched to your leads. The card is under CRM on Settings, Integrations. Nothing is stored until the credentials have been checked against ServiceTitan.

Before you start, in ServiceTitan

  • Your ServiceTitan account needs The Works package, which is what includes access to the API.
  • In the ServiceTitan developer portal, create a Customer app and choose the option that tenants will configure the credentials themselves.
  • Give the app read-only access to: Accounting > Invoices (Read), Accounting > Payments (Read), Job Planning and Management > Jobs (Read) and CRM > Customers (Read).
  • In ServiceTitan itself, go to Settings, then Integrations, then API Application Access, and generate a Client ID and Client Secret for the app. The secret is shown once; if you lose it, generate a new one.

Connect

Click Connect on the Service Titan card and fill in the four fields:

  • Tenant ID: The numeric ID of your ServiceTitan tenant.
  • Client ID: In ServiceTitan: Settings, then Integrations, then API Application Access.
  • Client Secret: Shown once when you generate it. If you have lost it, generate a new one.
  • App Key: From your app in the ServiceTitan developer portal.

When you click Connect, Local Wrangler reads one page of invoices from your account with exactly these credentials. Only if that works are they saved, with the secret and the app key encrypted. If it does not, the message says which part to check: a rejected Client ID and Client Secret, an app missing a read permission or not authorised for the tenant, or a Tenant ID that does not match the credentials.

What is imported, and when

Once a night, Local Wrangler reads your ServiceTitan customers, invoices and payments, and stores the payments. The first import reaches back 2years; each later run continues from where the last one stopped. A payment is matched to one of your customers by an exact email address or phone number, never by name, and then to that customer's most recent job or lead that already existed on the day the payment was made. A payment that matches nobody, or only a lead created after it, is kept but not attributed. Refunds, and payments without a date or an amount, are skipped and counted on the card.

What the card shows

Under the pill the card carries a Sync line. Before the first run it reads Not synced yet; when the status cannot be read it reads Sync status could not be loaded. After a run it reads Syncing nightly, or Last sync did not finish when the last run did not finish, followed by Last run, Payments stored, Matched and Skipped: when the run happened, how many payments are stored in all, how many of the last run's payments were matched to a lead, and how many records were skipped. One note appears when it applies: The last run did not finish. It will try again tonight. The last run covered part of the window and will continue tonight. Payments came in but none could be attributed to a lead yet. Payments older than the matching lead are kept but not attributed, and a contact with no matching email or phone is another reason.

The Events button lists one row per nightly run, marked ok, rejected when some records were skipped, or failed when the run did not finish, with the reason when one is recorded.

Disconnect

We will stop reading your Service Titan data until you reconnect. The payments already imported stay stored, and the Events history on the card is cleared. Connecting again continues from where the imports stopped rather than starting over.