Architecture, security, and trust
The systems behind the work.
Get a clear view of how XO Automotive connects dealership data, protects access, and approaches governance across the platform.
Designed to make operational data useful without treating every source system the same.
How we build
Direct answers, without the hand-waving.
XO Automotive is built to fit into real dealership operations. These answers describe our current product approach; deployment-specific controls and contractual commitments are confirmed during onboarding.
- 01Least-privilege access
- 02Purpose-limited data
- 03Traceable operations
Platform architecture
How the platform is organized.
Modular connections let each dealership use the systems it already depends on, while XO keeps downstream workflows consistent.
01What is the XO Automotive platform architecture?
+
XO Automotive uses a modular integration architecture: source-specific connectors collect approved dealership data, a normalization layer maps it into consistent business records, and product services use those records to power workflows, reporting, and customer-facing experiences.
02How do DMS and data-provider integrations fit into the platform?
+
Each provider connection is handled through its own adapter and configuration. That keeps provider rules, authentication methods, field names, and refresh behavior isolated while allowing XO products to work from a shared operating model.
03How are repair orders matched to inventory?
+
XO uses the identifiers available in the approved source data, such as VIN, stock number, dealer entity, and vehicle attributes. Matching is designed to retain lineage so teams can understand which source record supports a displayed service story.
04Does XO Automotive replace our DMS or inventory system?
+
No. XO is designed to extend approved source systems, not replace them. The DMS and inventory platforms remain the systems of record; XO uses approved data to create operational visibility and merchandising workflows.
05How are different dealer connections kept separate?
+
Connections are configured per dealer and per provider, with their own credentials, scopes, schedules, and source metadata. Product workflows are then limited to the records available through that dealer’s authorized connection.
Security and access
Controls that respect the data.
Security is built into connection handling and workflow design, with controls reviewed against the data and permissions each rollout requires.
06How are integration credentials handled?
+
Connection secrets are encrypted in the application before storage and are not returned to browser clients. Only the server-side integration workflow can use them to complete an approved connection.
07How is access controlled inside XO Automotive?
+
XO uses role-based access controls and dealer-level scoping. Administrative roles can manage users and authorized configurations, while dealer-team access is limited to the pages and data appropriate to that dealership account.
08How is data protected in transit?
+
External application and integration traffic is expected to use HTTPS/TLS. Provider-specific security requirements, including OAuth or WS-Security where applicable, remain part of the integration setup and certification process.
09Can XO prevent data from one dealership appearing in another dealer’s workflow?
+
That separation is a core design requirement. Dealer identity and source-connection context travel with imported records, and product queries are scoped to the account and connection a user is authorized to access.
10What activity can be traced or reviewed?
+
XO is designed to retain operational context around imports, connection configuration, matching outcomes, and workflow events. The exact audit record set and retention period are documented for each production deployment.
Compliance and governance
Built to support responsible operations.
Compliance is a shared discipline across XO, its dealers, and approved technology partners. We make the operating model legible so reviews are practical.
11Is XO Automotive a system of record for regulated dealership data?
+
XO is designed as an operational and merchandising layer. Source systems remain authoritative for their own records, and any regulated workflow is reviewed with the dealer and relevant provider before go-live.
12How does XO approach privacy and data minimization?
+
XO aims to use only the data required for the authorized workflow, limits access by role and dealer context, and avoids repurposing dealership data outside the agreed product use case.
13How does data retention work?
+
Retention is configured to support the approved workflow, reporting needs, and dealer agreement. Import schedules and cleanup rules can be adjusted by source so operational history is preserved only as long as it remains useful and authorized.
14What happens during an integration security review?
+
We document the data requested, intended use, dealer authorization, scopes, security requirements, and test workflow. For providers that require certification, XO supplies the required request examples and demonstrates the integration in the approved environment.
15How do we confirm the controls for our specific dealership group?
+
During onboarding, XO reviews the integration path, account roles, deployment environment, retention expectations, and any provider-specific obligations with your team. The result is a rollout plan that ties product access to the controls your organization expects.
Still have questions?
Let’s map the right architecture for your stores.
We’ll walk through your source systems, access model, and product priorities together.