Frequently Asked Questions

Without a shared format, every system that sends or receives leads must build a custom integration for every counterpart. A manufacturer working with twelve dealer groups needs twelve separate integration builds. Every time a dealer changes their CRM, that integration must be rebuilt from scratch.

The complexity compounds: N senders times M receivers equals N×M unique integrations across an ecosystem. An open standard collapses that to a single implementation per party — build once to LEX, connect to any LEX-compatible system. The integration cost shifts from a recurring operational tax to a one-time engineering investment.

The most common failure is silent data loss. A field that exists in the sending system simply does not exist in the receiving format, so it gets dropped without notice or error. Consent records, lead source attribution, asset interest details, pre-qualification signals — all of these routinely disappear at integration boundaries.

The receiving system often ends up with only a name, email, and phone number. The richer context that drove the customer's inquiry is gone. This degraded signal directly impacts conversion rates, makes follow-up calling feel cold and uninformed, and renders pipeline analytics unreliable.

Data loss also creates legal exposure: when consent evidence doesn't travel with the lead, the receiving party cannot demonstrate the legal basis for contacting the customer.

A customer researching a high-consideration purchase typically submits inquiry forms through multiple channels — a manufacturer's website, a third-party aggregator, and perhaps the dealer's own site. Without a standard deduplication mechanism, each of those submissions arrives in the dealer's CRM as a separate, unrelated record. The dealer's team calls the same prospect two or three times in the same afternoon.

The customer experience is immediately damaged. The dealer's apparent conversion rate is artificially deflated. Lead volume figures are inflated. And no party has a clear picture of how many real, unique buyers are actually in the pipeline.

LEX addresses this with a deterministic deduplication.customerFingerprint — a SHA-256 hash computed from normalized customer identity fields — present in every LEAD message. Any receiver can detect and collapse duplicate leads at the point of ingest, before they pollute the CRM.

Under GDPR, CCPA, DPDPA, and comparable privacy regulations, the legal basis for processing a customer's personal data must be demonstrable at every step: when they consented, through what channel, for what stated purpose, and under which regulatory jurisdiction.

Today, that evidence lives in the originating platform's internal database. It is almost never transmitted as part of the lead payload. When the lead reaches a third-party CRM, a dealer group, or a manufacturer's system, the receiving party has no documented evidence of consent. They must either re-obtain consent — an awful customer experience — or operate on legally uncertain ground.

LEX solves this by embedding a structured consentRecord object directly in every LEAD message. Consent evidence travels atomically with the data it authorizes, across every system it passes through.

Most lead transmission systems are fire-and-forget. The sender transmits a payload and then has no structured mechanism to learn whether the lead was received, whether someone contacted the customer, how the conversation progressed, or whether a deal closed.

This means originators cannot measure follow-up rates, lead aggregators cannot optimize traffic quality, and no party can close the attribution loop on a marketing campaign. The longer the sales cycle, the more severe this blind spot becomes.

LEX defines a full 15-status lead lifecycle with bidirectional acknowledgment and lead closure messages, giving every party in the pipeline a shared, structured vocabulary for describing where a lead currently stands — and a mechanism to communicate that state back to the originator in real time.

LEX is an open specification for the structure, content, and transport semantics of sales lead messages. It defines the message envelope, required and optional fields, allowed status values, consent record schema, deduplication fingerprint, extension mechanism, and conformance requirements.

It is not software, not a platform, and not a hosted service. Any system can implement LEX by reading the specification and emitting or consuming conformant messages. There is no SDK you are required to use, no vendor you are required to work with, and no membership required to participate.

LEX is focused specifically on the sales lead exchange use case: the structured transmission of customer intent, asset interest, consent evidence, and lifecycle status between parties in a sales pipeline.

It deliberately does not define procurement workflows, invoice formats, general-purpose supply chain messages, inventory management, or commerce transactions beyond the lead lifecycle. This focus is intentional: a tighter scope means a simpler standard, easier to implement correctly, and harder to corrupt through scope creep.

Broader commerce workflows are well-served by existing general-purpose EDI standards. The specific problem of lead exchange — buyer intent, consent, routing, deduplication, and lifecycle closure — is not.

The lead space is where a disproportionate share of integration pain concentrates. Every industry that sells high-consideration assets through a distributed dealer or partner network — vehicles, aircraft, vessels, heavy machinery, commercial real estate, enterprise software — shares the same core problem: a structured buyer intent signal that must travel accurately, with its full context and consent evidence intact, through multiple parties and systems over weeks or months.

This problem is under-served by general-purpose commerce standards. Purchase order and invoice formats were not designed for buyer intent signals, for routing logic, for consent records, or for deal closure attribution. LEX addresses that specific, unserved layer with the depth it deserves.

Yes. LEX defines a core message structure that applies to any industry selling through a lead-based pipeline. An extension namespace system allows industry-specific fields to be added alongside the core without modifying shared definitions.

Aviation, maritime, heavy equipment, real estate, and technology are all supported today with published extension namespaces in the public registry. The extension registry is open — any organization can publish a namespace extension for their specific domain, and the core standard is unaffected.

LEX supports four wire formats:

• JSON-EDI — the recommended format for all new integrations. Human-readable, REST-friendly, and easy to validate with standard JSON tooling.
• XML-EDI — for systems that require XML, including legacy integrations and environments with XML-based validation pipelines.
• ASC X12 850 mapping — for connection to established EDI networks using legacy X12 infrastructure.
• EDIFACT ORDERS mapping — for international EDI infrastructure where EDIFACT is the norm.

All four carry semantically equivalent content. A JSON-EDI message and an X12 850 message built from the same lead data represent the same lead — no information is lost in translation between formats.

Each LEAD message may include a deduplication.customerFingerprint field containing a SHA-256 hash computed from a normalized representation of the customer's email address, phone number, and last name.

The normalization rules — lowercasing, whitespace stripping, international phone normalization — are fully specified so that any two compliant implementations produce the same fingerprint for the same customer, regardless of how the source data was formatted. A receiver stores fingerprints at ingest, and can immediately detect when an incoming lead represents a customer already in their pipeline. The duplicate can be silently merged or flagged for review, before it reaches the CRM.

Yes. LEX defines an explicit extension mechanism: any field prefixed with lex.ext.[namespace] is a recognized extension. Namespaces are registered in the public extension registry, preventing collisions between organizations.

A receiver that does not understand an extension field ignores it safely — the core message remains schema-valid. Extensions are strictly additive: they cannot change the semantics of a core field, make a previously optional field required, or remove existing values from enumerations. This guarantee means extension adoption by one party cannot silently break integrations with parties unaware of that extension.

LEX defines 15 lead status values covering the full sales pipeline:

Allowed transitions are defined by a state machine in the specification. Every party in the pipeline uses this shared vocabulary, eliminating ambiguity about where a lead stands and which terminal states are valid.

Yes. A LEAD message flows from originator to receiver. The receiver is required to send an ACKNOWLEDGMENT back, confirming receipt and validation status. As the lead progresses, the receiver emits structured status updates and eventually a LEAD_CLOSURE message back to the originator.

This creates a fully closed-loop pipeline: the lead source knows a lead was received, knows when a customer was contacted, and knows when a deal closed — all through machine-readable LEX messages, without manual reporting or proprietary dashboard integrations. Every transition is a validated, structured message.

The LEX specification is published under the Apache License, Version 2.0. Any party can implement it freely and permanently — that right cannot be revoked by any future governance decision.

Apache 2.0 was chosen over MIT specifically because it includes a patent retaliation clause: if any contributor or implementer brings a patent lawsuit claiming that the LEX specification or a conformant implementation infringes their patents, their license to the specification terminates. MIT has no such protection. This clause protects every adopter in the ecosystem from patent ambush by contributors, making Apache 2.0 the stronger choice for a technical standard.

The specification also includes an explicit anti-capture clause: if any single entity or coordinated group gains majority control of the governing body, the specification automatically forks under independent governance. LEX is designed to remain ungovernable by any single commercial interest, including its own most active contributors.

No. Implementing LEX requires no payment, registration, or approval of any kind. Conformance levels are self-declared against public test vectors published on GitHub. No certification body is mandatory.

Third parties may offer certification services as a commercial value-add, but their involvement is entirely optional and does not gate access to the standard, the ecosystem, or any LEX-compatible platform.

Run the public test case library against your implementation. Pass all Level 1 test cases and you may claim L1 conformance in your product documentation. Pass Level 2 test cases and claim L2. Pass all Level 3 test cases and claim L3.

The test case library is published in the GitHub repository and versioned alongside the specification. There is no registry to submit to, no approval to wait for, and no annual fee to maintain your declaration. See the Conformance page for the full test vector index.

LEX uses semantic versioning. Backward-compatible additions — new optional fields, new status values, new extension namespaces — increment the minor version. Breaking changes increment the major version and require a defined deprecation period with advance notice and migration guidance.

A core design constraint is that a receiver implementing LEX v1.x must be able to process any v1.y message without failure, for any y > x. Optional fields remain optional. Enum values are never removed without a full major version cycle. The standard grows through public proposals on GitHub, open comment periods, and community consensus — not through private decisions by a single sponsor.

Open an issue or pull request on the GitHub repository at github.com/lexstandard/lex. All proposals are public from the moment they are submitted — there is no private track.

The governance process requires a written rationale explaining the problem being addressed, an open comment period during which any stakeholder may respond, and no sustained objection from a qualified majority of active maintainers. An organization that has deployed LEX widely has exactly the same voice in this process as an individual implementer.