Sage 300 and ServiceTitan integration

What moves between them

The main flow runs from ServiceTitan into Sage 300. Invoices created in ServiceTitan flow into Sage 300 as AP invoice batches, and payments flow in as payment records. Vendors are synced in both directions so service operations and accounts payable use the same vendor master. Reference data such as vendor groups and account sets are read from Sage 300 and used to validate vendor records from ServiceTitan. Sage 300 journal batches are posted on a schedule, typically at the end of each business day or after each invoice is created in ServiceTitan.

How ml-connector handles it

ml-connector accepts the Sage 300 customer-hosted URL and uppercase Basic Auth credentials, and stores the ServiceTitan OAuth2 client credentials and App Key encrypted. On the ServiceTitan side, it registers a webhook endpoint to push invoice and payment events, and it caches the OAuth2 bearer token (valid 15 minutes) to avoid token requests per call. On the Sage 300 side, it polls for vendor updates on a schedule, since Sage 300 has no webhooks. When a ServiceTitan invoice arrives, ml-connector maps it to the matching Sage 300 vendor and GL account, creates an AP invoice batch, and posts it. Payments flow the same way into APPaymentAndAdjustmentBatches. If a ServiceTitan call returns a 429 (rate limit), ml-connector backs off and retries. If Sage 300's IIS AppPool times out during a large poll, the request is retried with exponential backoff. Vendor master records are deduplicated by external ID (ServiceTitan internal ID mapped to a Sage 300 vendor key), so updates on either side do not create duplicates.

A real-world example

A mid-sized HVAC and plumbing contractor runs ServiceTitan for job scheduling, dispatch, and invoicing across multiple service lines and locations. They also run Sage 300 on-premise for general ledger and accounts payable. Before the integration, invoices created in ServiceTitan were exported weekly and re-entered into Sage 300 by hand, and vendor master changes had to be updated in both systems to avoid mismatches. With ServiceTitan and Sage 300 connected, each service invoice reaches accounts payable instantly, vendors are synchronized, and the accounting team can focus on analysis instead of data re-keying.

What you can do

• •Push ServiceTitan invoices and payments into Sage 300 as AP invoice and payment batches on every creation or update.
• •Sync vendors in both directions so service operations and accounts payable share a single master record.
• •Authenticate Sage 300 with HTTP Basic Auth and ServiceTitan with OAuth2 and the required App Key header.
• •Handle Sage 300 polling for vendors and ServiceTitan webhook push for invoices and payments, with retries and backoff on rate limits and timeouts.
• •Maintain a full audit trail of every record moved, with replay capability if a downstream posting fails.

Questions

How does ml-connector bridge Sage 300's Basic Auth and ServiceTitan's OAuth2?

ml-connector stores both credential sets encrypted. For Sage 300, it encodes the uppercase username and password into the Basic Auth header on every request. For ServiceTitan, it obtains an OAuth2 bearer token using client credentials, caches it for the 15-minute lifetime, and includes the ST-App-Key header on every call.

Does Sage 300's lack of webhooks mean ServiceTitan changes are delayed?

Vendors are polled from Sage 300 on a schedule, so changes in Sage 300 propagate to ServiceTitan within the polling window. ServiceTitan changes (invoices, payments) are pushed via webhooks to ml-connector in real time, so they reach Sage 300 within seconds of creation.

What happens if Sage 300's IIS server times out or ServiceTitan hits its rate limit?

ml-connector detects HTTP 429 (rate limit) and IIS timeouts, backs off exponentially, and retries the request. Each record attempt is logged in the audit trail, so failed requests can be replayed once the underlying issue is resolved.