The open successor to ADF-XML — built for real-world automotive commerce.
A JSON-native protocol modeling the full transaction lifecycle, from first conversation through negotiation, financing, delivery, and post-sale events.
From ADF-XML to ACP — how automotive commerce data evolves into a structured, lifecycle-aware protocol.
ADF-XML served the industry for two decades. ACP extends that foundation with the data structures modern automotive commerce requires.
Every ACP envelope is a self-contained commerce document with a defined structure.
Eight stages model the full deal lifecycle. Stage progression is non-linear and represents snapshot state at time of transmission.
Receivers MUST NOT assume linear progression. Stages may be skipped, repeated, or reversed. The closed_lost stage is terminal — a new transaction should be created if the customer re-engages.
ACP envelopes are full state snapshots by default. Event-only delta envelopes are supported for real-time streaming.
Delta envelopes contain only acp + events and reference a parent via parent_envelope_id. The JSON Schema enforces this: if parent_envelope_id is present, no other top-level objects
are permitted.
{
"acp": {
"version": "1.0.0",
"protocol": "acp",
"envelope_id": "acp_1739456200_x8k2"
},
"source": { ... },
"dealership": { ... },
"lead": {
"id": "lead_1739456200",
"status": "qualified",
"score": 82
},
"transaction": {
"id": "txn_1739456200_m4k8",
"stage": "negotiation",
"offer_history": [ ... ]
},
"conversation": { ... },
"events": [ ... ],
"ai_analysis": { ... }
}
{
"acp": {
"version": "1.0.0",
"protocol": "acp",
"envelope_id": "acp_1739456338_d01",
"parent_envelope_id": "acp_1739456200_x8k2"
},
"events": [
{
"type": "intent_detected",
"timestamp": "2025-02-13T15:32:18Z",
"data": {
"type": "TEST_DRIVE",
"confidence": 0.97
}
}
]
}
ACP is designed for incremental adoption. Existing ADF-XML workflows continue to function throughout the migration.
ACP is in active production use. The following platforms produce or consume ACP envelopes.
ACP evolves through a public RFC process with multi-stakeholder advisory board governance.
All specification changes go through a formal Request for Comments process with a 30-day public comment period. Anyone can submit proposals via the public issue tracker.
5–9 members representing agent platforms, CRM vendors, DMS providers, and independent contributors. Rotating chair. No single vendor controls the protocol.
Changes to required fields or envelope structure require two-thirds supermajority approval and 12-month deprecation notice. Migration guides published before every major release.
The specification, schema, and all tooling are Apache 2.0 licensed. Two Advisory Board seats are permanently reserved for independent community contributors.