ServiceTitan Provider Boundary

Summary

ServiceTitan is a useful provider-boundary example because it spans many operational domains: CRM, jobs, dispatch, accounting, payroll, inventory, settings, memberships, and more. The reusable lesson is breadth control: a broad provider should be adapted once at the edge and normalized inward through lakehouse and service boundaries.

Reader Question

How should a platform integrate with a broad operational provider without letting provider-specific auth, pagination, endpoint behavior, and field shape spread into every workflow?

Boundary Pattern

Provider clients and endpoint wrappers belong at the integration edge. Ingestion pipelines capture provider facts into source-shaped layers. Canonicalization and domain services then expose provider-backed data through stable internal contracts.

That separation lets downstream workflows ask operational questions without speaking provider API dialect. Payroll, marketing, finance, and review surfaces can depend on domain services and data products rather than each implementing their own provider access.

Reusable Lessons

  • Broad providers need a boundary per provider plus domain-specific internal read models.
  • Incremental source seeding should be deterministic and replayable.
  • Provider-shaped data should not become UI truth directly.
  • Cross-domain use is a reason to strengthen boundaries, not bypass them.
  • Integration code can be messy at the edge if it normalizes aggressively inward.

Source Evidence

  • integrations/ext_servicetitan
  • pipelines/lakehouse/ingest/servicetitan
  • services/lkci_lakehouse/services/domains/servicetitan
  • docs/domains/lakehouse.md