Implementation Quality

Conformance Levels

LEX defines three tiered conformance levels. They are self-declared against published test vectors. There is no mandatory certification body, no fees, and no approval delays.

Open Conformance Model

Conformance levels are self-declared. Run the public test case library against your implementation and declare the level you pass. Any third-party may offer certification services, but no certification body is mandatory. An implementation is not blocked from the LEX ecosystem because it has not paid for certification.

Conformance Levels

Basic

Minimum for any production integration

Required for production

Requirement	Description
Valid message envelope	Produce and parse `lex.header` + `lex.payload`
Required field compliance	All required fields present in every message
MessageID uniqueness	No duplicate messageIds sent within a session
Timestamp validity	Timestamps within ±60 seconds of clock time
ACKNOWLEDGMENT response	Send ACK for every received LEAD message

Standard

Required for DMS integration partners

DMS integration

All Level 1 requirements, plus:

Requirement	Description
Full lifecycle support	Send and receive all 15 lead status values
Status transition validation	Reject invalid status transitions with correct error code
Business rule validation	Email (RFC 5322), phone (E.164), VIN, financing fields
Lead Closure support	Send and receive LEAD_CLOSURE messages
Bidirectional flow	Can both initiate and respond to lead messages

Full

Required for OEM and platform certification

OEM & platform

All Level 2 requirements, plus:

Requirement	Description
Consent record compliance	`consentRecord` present and valid for all PII-bearing messages
Deduplication support	Sends `customerFingerprint`, handles `DUPLICATE` closure
EV extensions	Can parse and produce the `evSpecifications` block
Lead intelligence passthrough	Preserves `leadIntelligence` without modification
Retry and DLQ headers	Produces `retryContext` on retry; routes to DLQ on permanent failure
Multi-format support	Can parse JSON-EDI and XML-EDI
Subscription management	Full SUBSCRIPTION message send/receive
Organization context	`organizationContext` correctly populated

Test Case Library

Run your implementation against the canonical test vectors to determine your conformance level. All test cases are open and publicly available.

L1 TC-001

Valid Primary Lead

Input: well-formed LEAD with all required fields. Expected: valid: true, ACK with RECEIVED

L1 TC-002

Missing Required Field

Input: LEAD missing customer.firstName. Expected: REQUIRED_FIELD_MISSING

L1 TC-003

Invalid MessageType

Input: messageType: "INQUIRY". Expected: CRITICAL error on header

L1 TC-004

Duplicate MessageID

Two LEAD messages with identical ID ≤60s. Expected: 200 OK, no duplicate processing

L1 TC-005

Future Timestamp

Timestamp 5 minutes in the future. Expected: TIMESTAMP_IN_FUTURE

L2 TC-006

Invalid Email Format

email: "not-an-email". Expected: INVALID_EMAIL_FORMAT

L2 TC-007

Invalid Status Transition

Transition from DELIVERED → SHOPPING. Expected: INVALID_STATUS_TRANSITION

L3 TC-010

Consent Record Present

PII-bearing LEAD must carry valid consentRecord block

L3 TC-011

EV Spec Block

LEAD with EV product must produce and parse evSpecifications

View Full Test Case Library

Key Validation Rules

# Email — RFC 5322

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

# Phone — E.164

^\+?[1-9]\d{1,14}$

# Timestamp bounds

future: < +60s · past: < 24h

# Financing — loan term

loanTerm: 12–84 months · monthlyPayment > 0