IFS Cloud and ServiceTitan integration

What moves between them

The primary flow moves purchase orders and GL posting proposals from IFS Cloud into ServiceTitan's procurement and accounting workflows. When IFS creates or modifies a purchase order, ml-connector polls the OData API, captures the record with its current ETag, and writes it into ServiceTitan for vendor management and procurement tracking. Similarly, GL posting proposals from IFS are read on a schedule and synced into ServiceTitan's accounting records, mapped to the appropriate cost centers and vendor accounts. Supplementary flows can pull ServiceTitan invoices and jobs back into IFS Cloud as source records for GL vouchers or GL account postings, completing the two-way financial reconciliation. Because IFS Cloud has no webhooks, polling occurs on a schedule aligned with your accounting close cycle. ServiceTitan's webhooks are optional; when enabled, they notify ml-connector of new or updated invoices and jobs, accelerating the read-back flow.

How ml-connector handles it

ml-connector stores both OAuth2 credential sets encrypted and handles the distinct token lifetimes: IFS tokens (60 minutes) and ServiceTitan tokens (15 minutes, cached). On the IFS side, ml-connector constructs tenant-specific OData URLs per customer, polls purchase orders and posting proposals with filters on creation or modification timestamps, and captures the ETag header on every read so that mutations include the If-Match header for optimistic concurrency control. Before creating a purchase order in IFS, ml-connector queries by order number to prevent duplicates, since IFS OData lacks a built-in idempotency key. On the ServiceTitan side, ml-connector presents the required ST-App-Key header on every call, validates the Tenant ID in the URL path, and verifies webhook signatures with HMAC-SHA256 when webhooks are enabled. Purchase order amounts are mapped to the correct vendor and tax zone in ServiceTitan. GL posting proposals are mapped to the corresponding GL accounts and cost centers in ServiceTitan's native accounting dimension. Rate limits are respected: exponential backoff with jitter for IFS's approximate 1000 req/min limit, and strict adherence to ServiceTitan's 60 req/sec ceiling. Every record carries a full audit trail, and failed syncs are logged so they can be replayed once the underlying issue is resolved.

A real-world example

A regional HVAC and plumbing contractor runs IFS Cloud for enterprise finance, procurement, supply chain, and asset management across five service regions, and uses ServiceTitan to dispatch technicians, schedule jobs, and manage invoicing for customer service calls. Before the integration, the procurement team manually entered IFS purchase orders into ServiceTitan to track inventory parts for field service, and the accounting team exported vendor invoices from ServiceTitan and re-keyed them as GL posting proposals in IFS during month-end close, a process prone to data entry errors and reconciliation delays. With IFS Cloud and ServiceTitan connected, each purchase order created in IFS automatically flows into ServiceTitan's procurement system for field inventory tracking, and service invoices from ServiceTitan are pulled back into IFS as GL posting proposals, allocated to the correct cost center for each region. The finance team now reconciles AP and inventory variance in under two hours instead of two days, and the procurement team has real-time visibility into which field parts are on order.

What you can do

• •Sync purchase orders from IFS Cloud into ServiceTitan for vendor procurement and field-service inventory tracking, including vendor and cost allocation.
• •Pull ServiceTitan invoices and jobs back into IFS Cloud as GL posting proposals, mapped to the correct GL accounts and cost centers for automated month-end close.
• •Handle IFS's ETag-based optimistic concurrency by reading each record with its current ETag and including the If-Match header on mutations.
• •Authenticate both systems independently, managing distinct OAuth2 token lifetimes (IFS 60 minutes, ServiceTitan 15 minutes cached) and ServiceTitan's required ST-App-Key header.
• •Poll IFS on a schedule since it has no webhook API, while optionally receiving ServiceTitan webhook notifications when enabled, with full audit trail and replay capability on failed records.

Questions

How do purchase orders flow from IFS Cloud into ServiceTitan?

ml-connector polls the IFS OData API on a schedule aligned with your procurement cycle, retrieving purchase orders filtered by creation or modification timestamp. Each order is captured with its current ETag header, ensuring optimistic concurrency control. The order is then written into ServiceTitan's procurement system, mapped to the corresponding vendor and tax zone. Amounts, vendor codes, and item descriptions are preserved in the sync.

What is the role of the ETag header in the IFS Cloud integration?

IFS Cloud requires ETag headers (If-Match) for mutation operations to prevent concurrent overwrites. When ml-connector reads a purchase order or GL posting proposal from IFS, it captures the ETag value. If the record needs to be updated, ml-connector includes that ETag in the PATCH request. If the record has changed since the read, IFS rejects the mutation with a conflict response, protecting against lost updates. ml-connector retries after re-reading the current state.

Can ServiceTitan invoices and jobs be synced back into IFS Cloud?

Yes. ml-connector can pull ServiceTitan invoices and jobs from the REST API or via webhook notifications, then write them into IFS Cloud as GL posting proposals or GL vouchers, mapped to the correct GL accounts and cost centers. This bidirectional flow closes the accounting cycle without manual re-entry, though AP bill creation in ServiceTitan is read-only (auto-generated from purchase orders), so those records flow one direction into IFS.