ServiceTitan app approval path
Owner: PageToJob
No marketplace or partner approval is claimed in the offline product.
Next: Confirm app type, app key handling, review requirements, sandbox access, and approval timeline.
API readiness
ServiceTitan API and partner readiness pack
A customer-safe checklist for moving from manual ServiceTitan-ready websites to approved API-backed sync, attribution, drift monitoring, and partner review without overpromising before access exists.
Readiness summary
5
ready now
3
engineering required
2
partner gated
4
runbooks
This page is a readiness pack, not an integration claim. It keeps manual product value separate from API-backed future work.
Approval and engineering checklist
partner gated
Customer consent and admin authorization
Owner: Customer
Manual Launch and Growth packages can run from customer-reviewed exports and screenshots while the access checklist names the future ServiceTitan admin and module gates.
Next: Use /servicetitan-ready-websites/access-checklist to confirm the admin contact, enabled modules, acceptable manual artifacts, and later authorization owner.
Scope-to-feature map
Owner: PageToJob
Connection readiness matrix already separates CRM, job, settings, dispatch, marketing, pricebook, memberships, and accounting scopes.
Next: Attach each paid feature to its minimum eligible module and granted scope before selling automation.
Encrypted credential and token storage
Owner: PageToJob
The offline demo stores no ServiceTitan credentials, tokens, or secrets.
Next: Design encrypted token references, rotation, disconnect, deletion, and audit logging before accepting live credentials.
Webhook verification and replay protection
Owner: PageToJob
Webhook behavior remains documented as a requirement; no production webhook endpoint is claimed.
Next: Validate raw-body verification, replay windows, idempotency keys, event storage, and failure handling in sandbox.
Asynchronous sync and retry queue
Owner: PageToJob
The offline sync queue shows queued, review, retrying, blocked, and manual-complete states without processing jobs.
Next: Persist sync attempts, idempotency keys, retry windows, external IDs, and operator-visible failure states after database and API access exist.
Privacy, retention, and deletion policy
Owner: Shared
The security packet and implementation playbook define lead, booking envelope, Titan Map, export, and token retention boundaries before API-backed transfer exists.
Next: Use /servicetitan-ready-websites/security as the customer-facing policy packet and update it after live database/API retention behavior is implemented.
Data boundaries
Website lead and booking request
Current: Local form submission and notification fallback.
Future: Approved CRM lead or booking handoff with external IDs and retry status.
Never block visitor submission on ServiceTitan availability.
Job types, business units, campaigns, zones, memberships, and pricebook
Current: Customer-reviewed manual Titan Map and fake/demo taxonomy.
Future: Read-only imports where scopes and purchased modules allow.
Keep public website publishing controlled by PageToJob review, not automatic writes from imported data.
Bookings, jobs, invoices, payments, and revenue
Current: Demo outcomes or supplied exports for manual proof packets.
Future: Matched booked jobs and revenue where Marketing/Accounting access is authorized.
Do not claim closed-loop revenue proof unless the source and match quality are visible.
Scheduling Pro and ServiceTitan webhook events
Current: No webhook receiver is treated as production-ready.
Future: Verified, idempotent event ingestion with replay protection and operator-visible processing state.
Reject unsigned, stale, duplicate, or unrecognized events before processing.
Support runbooks
Failed booking or lead sync
A queued booking or lead handoff cannot be delivered after retries.
- - Keep the PageToJob lead record and business notification intact.
- - Show the failed sync in ops with tenant, mapping, status, last error, and next retry.
- - Let the operator resend, mark manual, or correct the Titan Map binding.
Customer never loses a website lead because an external sync failed.
Customer disconnect or revoked scopes
A customer revokes authorization, scopes expire, or the connection fails eligibility checks.
- - Disable API-backed automation for the tenant.
- - Keep manual booking fallback, Titan Map review, and drift review active.
- - Record disconnect time, affected features, and required customer action.
The website remains operational in no-API mode.
Imported taxonomy conflicts with live site copy
A job type, zone, campaign, offer, membership, or pricebook item appears inactive or mismatched.
- - Create a drift finding instead of silently changing the public website.
- - Assign owner, severity, affected URL, recommended fix, and customer review state.
- - Resolve only after the customer confirms the operating change.
Operations changes become reviewable fixes, not surprise website edits.
Outcome or revenue attribution mismatch
A website lead cannot be confidently matched to a booking, job, invoice, payment, or campaign outcome.
- - Label the record as unmatched or needs review.
- - Show source fields, candidate external IDs, and missing match criteria.
- - Exclude uncertain records from revenue claims until reviewed.
Proof packets stay honest about match quality and data source.
Partner review materials
Security and privacy summary
Owner: PageToJob
The security packet documents current no-credential mode, data minimization, consent artifacts, and future encrypted storage requirements.
Next: Review /servicetitan-ready-websites/security with buyer, legal, and partner reviewers before requesting app approval.
Data-flow diagram and access justification
Owner: PageToJob
The partner application packet and access checklist map each future API family to a minimum product use, module gate, and customer authorization owner.
Next: Translate the scope justification into final data-flow diagrams after app review requirements are confirmed.
Support and escalation process
Owner: Shared
Manual runbooks and partner packet support model define failed syncs, disconnects, drift conflicts, attribution mismatch, and response windows.
Next: Assign named support owner and final customer-facing escalation copy.
Sandbox validation evidence
Owner: PageToJob
No sandbox tenant evidence exists in the offline product; the sandbox validation protocol defines the required tests without claiming access.
Next: Use /servicetitan-ready-websites/sandbox-validation to capture approved tests for token exchange, imports, webhooks, handoff, retries, disconnect, deletion, and rate limits.
Claims still gated
- - Marketplace partner approval
- - Live ServiceTitan OAuth or app authorization
- - Automatic lead, booking, job, invoice, payment, or pricebook sync
- - Webhook-driven Scheduling Pro event processing
- - Closed-loop revenue attribution from live ServiceTitan data
Required disclaimer language
- - PageToJob is not affiliated with or endorsed by ServiceTitan.
- - ServiceTitan is a trademark of its respective owner.
- - This readiness pack is not evidence of ServiceTitan marketplace approval, app approval, live tenant access, or granted scopes.
- - API-backed features require customer authorization, eligible ServiceTitan products/modules, granted scopes, approved app access, secure token storage, and sandbox validation.