Integrate with ServiceMax Asset 360 by working through Salesforce's own APIs against its managed-package objects.
domain: support.ptc.com · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Recognize that ServiceMax Asset 360 has no separate ServiceMax REST API — it installs as a managed package inside the customer's Salesforce org and rides on the standard Salesforce Field Service data model.
Use the standard Salesforce REST/Bulk/Composite API (OAuth2 against the org) to read/write ServiceMax's custom objects and the underlying Field Service objects (WorkOrder, ServiceAppointment, Asset).
Consult the Asset 360 Data Model reference to identify which custom (SVMX-prefixed) objects your integration needs versus core Salesforce Field Service objects.
Respect the customer's field/object-level security — ServiceMax's managed package enforces its own permission layer on top of Salesforce's.
Test against a sandbox org with Asset 360 installed, since managed-package object schemas can differ by installed package version.
Known gotchas
Treating ServiceMax as if it had its own public API (like ServiceTitan or Jobber) is the most common design mistake — all access is via Salesforce org APIs.
Managed-package object/field names and required fields can shift between Asset 360 releases; don't hardcode against one version's schema without checking the customer's installed version.
Because it's Salesforce-hosted, standard Salesforce API limits (per-org call limits, Bulk API limits) apply on top of anything ServiceMax-specific.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?