The ADF lead: every field a CRM receives, and the three that decide routing
In short
An ADF lead is an XML document carrying a car enquiry from a marketplace or website into a dealership CRM. Its envelope has five parts — prospect, customer, vehicle, vendor and provider — and three fields carry the whole downstream workflow: requestdate, the vehicle of interest, and the provider that sent it. Everything else should be parsed as optional.
Key takeaways
- ADF stands for Auto-lead Data Format: an XML envelope, usually delivered inside an email rather than over an API.
- The 5 sections are prospect, customer, vehicle, vendor and provider, and only the first two are reliably complete.
- requestdate is when the customer submitted, not when you received it — every response-time number depends on the difference.
- The vehicle block identifies a car loosely: year, make and model arrive far more often than VIN or stock number.
- Senders extend the format freely, so a parser that rejects unknown elements will silently drop real enquiries.
ADF — Auto-lead Data Format — is the XML document a marketplace, website form or third-party service sends when a shopper enquires about a car. It usually arrives as an email, XML in the body or attached, and the CRM parses it into a lead record. The format dates from the late 1990s, has never been strictly policed, and every sender extends it differently.
That history is the practical point. ADF is a convention rather than a contract, and an integration written as though the schema is guaranteed loses leads a looser one would keep.
The envelope, section by section
| Section | What it carries | How often it is usable | When it is missing |
|---|---|---|---|
| requestdate | Timestamp of submission, ISO 8601 with an offset | Almost always present; the offset is not | Response-time reporting silently measures the wrong interval |
| customer / contact | name (part="first"/"last"), email, phone (type, time), address, comments, timeframe | Name and one channel are near-universal; both channels are not | The lead is unreachable, or de-duplication has nothing to match on |
| vehicle | interest and status attributes, year, make, model, trim, vin, stock, odometer, price | Year, make and model usually; vin or stock far less often | You cannot join the enquiry to inventory before replying |
| vendor | The receiving store: vendorname, id, contact, and often the store's own reference | Usually present, frequently wrong for multi-rooftop groups | Leads route to the group rather than to a store |
| provider | Who generated and sent the lead: name, service, id, url | Present but inconsistently named across senders | Source attribution collapses to "other" |
The document is wrapped in an adf root with a prospect element carrying a status attribute, and identifiers appear as id elements with a source attribute rather than as a single primary key. There is no universal lead id: the pairing of provider and the provider's own id is the closest thing you have, and de-duplication has to be built on it.
The three fields everything downstream is built on
- requestdate. The moment the shopper pressed submit, not the moment the message reached your inbox. Every response-time metric, every SLA and every overnight-queue rule is arithmetic on this field, and a missing timezone offset can move a lead by hours — see when the response clock starts.
- The vehicle of interest. It decides which department, which team and often which salesperson receives the lead, and whether the first reply can name a car still in stock. New versus used status routes differently in most stores.
- provider. It sets the source code, and therefore attribution, cost accounting and every marketplace performance conversation. Because senders name themselves inconsistently, this field needs a mapping table — the reason three systems give three answers about where a lead came from.
Parse it as though every element is optional
- Never fail closed on a schema error. A parser that rejects a document it cannot validate produces the gap in the marketplace saying it sent 40 leads when your CRM has 31. Store the raw payload, create the lead, flag the defect.
- Treat phone and email as a set, not as fields. Multiple phone elements with type and time attributes are normal; pick a contact channel by rule rather than by position in the document.
- Expect free text where you wanted structure. Trade-in details, finance questions and part-exchange registrations usually arrive inside comments, not in their own elements.
- Keep unknown elements. Senders add their own; discarding them loses chat transcripts, campaign identifiers and appointment preferences that only that sender provides.
- Normalise the name yourself. part="first" and part="last" are common, part="full" is common too, and one sender in any given month will send both.
What ADF does not carry
It does not carry consent state, so contact permissions have to be established by your own process rather than read off the lead. It does not carry marketing attribution beyond the sending provider — campaign, keyword and landing page are not in the envelope. It carries no status vocabulary for what happens next, which is why a store needs its own disposition codes an automated follow-up can branch on.
Treat ADF as a well-behaved suggestion. The leads you lose are almost never malformed enquiries; they are valid enquiries your parser decided were malformed.
Getting this layer right is unglamorous and it is where lead loss actually lives. It sits at the front of everything else in lead response and follow-up, and it is the first thing we look at in software and AI systems for dealerships. Automating the reply that follows is AI agents and automation work, with the reliability constraints set out in AI agents in production.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Is ADF still used, or has it been replaced by APIs?
It is still the default way third-party enquiries reach a dealership CRM, and email is still the usual transport. Some providers offer direct API delivery and some CRMs accept it, but a store receiving leads from several marketplaces will have ADF in the mix, so any lead pipeline has to parse it.
What is the difference between the vendor and provider sections?
Vendor is the dealership receiving the lead; provider is the service that generated and sent it. Confusing the two breaks routing and attribution at once: the store looks like the source of its own leads, and multi-rooftop groups cannot tell which location an enquiry belongs to.
Why do response-time numbers disagree between the marketplace and the CRM?
Because they measure from different clocks. The marketplace measures from requestdate, which is when the shopper submitted; the CRM often measures from when the email was received and parsed, which can be minutes or hours later. Reconcile by always storing both timestamps on the lead record and reporting from requestdate.
Can we require VIN or stock number from lead providers?
You can ask, and some will comply for enquiries raised against a specific listing, but you cannot depend on it. Build the join the other way: match year, make, model and trim against live inventory, present the candidates to the responder, and treat vin or stock as a shortcut when it happens to arrive.
- ADF
- lead handling
- CRM integration
- data formats
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- Lead source codes: why 3 systems give 3 answers on where a lead came fromSource in the CRM, in analytics and on the vendor invoice answer 3 different questions. Nominate one as the operational answer and stop reconciling the other two.definition
- Disposition codes: 'no answer', 'not now' and 'not a buyer' differA disposition is not a note about the call. It is the instruction for what happens next, and a value naming no single action and owner cannot be automated.definition
- The marketplace says it sent 40 leads and your CRM has 31A vendor's lead count and your CRM's lead count disagree for four different reasons, and from inside the CRM all four look identical. Here is the reconciliation that tells them apart.diagnostic
- What an up log is, and why the software version never matches the floorThe up log is a dealership's floor-traffic record, not a CRM record — and because the person who fills it in has usually just lost the sale, the number it produces is a floor, not a total.definition
Related across the site
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation