ADF XML Lead Format: What Every Internet Manager Should Know

What ADF is and where it came from

ADF stands for Auto-lead Data Format, a small XML vocabulary for describing a car shopper's inquiry so that any system can read it. When a shopper submits a form on a listing site, an OEM site or your own website, the lead often reaches your CRM as an ADF email.

The standard's own revision history dates the first draft to December 18, 1998. Later drafts took comments from Reynolds and Reynolds, Autovantage, Stoneage, Cobalt, Microsoft, Cars.com, AutoSite and Kelley Blue Book. A March 2000 draft added the email transfer method, and version 1.0 was marked final on May 3, 2000 (ADF 1.0 specification).

Its stated goals for dealers still read like an internet manager's wish list: "Consolidate leads from multiple sources" and "Reduce errors caused by manual handling of customer information." Dealer Inspire hosts the spec at adfxml.info, calling ADF "an industry standard for sharing lead information between tools that help manufacturers and dealers sell more cars."

An example ADF lead

Here is a short, valid ADF lead for a fictional shopper who wants a used RAV4 and has a trade:

<?xml version="1.0" encoding="UTF-8"?>
<?adf version="1.0"?>
<adf>
  <prospect status="new">
    <id sequence="1" source="CarGurus">CG-20260926-4417</id>
    <requestdate>2026-09-26T19:42:10-06:00</requestdate>
    <vehicle interest="buy" status="used">
      <year>2023</year> <make>Toyota</make> <model>RAV4</model>
      <stock>P4127</stock> <trim>XLE</trim>
    </vehicle>
    <vehicle interest="trade-in" status="used">
      <year>2017</year> <make>Honda</make> <model>CR-V</model>
      <odometer units="mi">88400</odometer>
    </vehicle>
    <customer>
      <contact>
        <name part="first">Sarah</name> <name part="last">Lopez</name>
        <email>sarah.lopez@example.com</email>
        <phone type="cellphone">303-555-0142</phone>
      </contact>
      <comments>Is this one still available? Could I drive it Saturday?</comments>
    </customer>
    <vendor>
      <vendorname>Premier Auto</vendorname>
      <contact><name part="full">Internet Sales</name></contact>
    </vendor>
    <provider><name part="full">CarGurus</name></provider>
  </prospect>
</adf>

Top to bottom, that is the whole lead: who asked, when, about which car, with what trade, from which site, for which store. The comment is the line to read twice, because it holds the customer's actual question.

The spec sets a low bar. Only four things are required:

• The date and time of the request
• The vehicle's year, make and model
• The customer's name and either a phone number or an email address
• The vendor (dealer) name

Everything else is optional, which is why two providers can send very different leads that are both valid ADF.

The key ADF elements and what each is for

prospect and id

One ADF document can hold several <prospect> leads. The status attribute marks a first send ("new") or a repeat ("resend"). The optional <id> carries the sender's lead number and source, and the spec notes that "different sources may use different ids for the same data as it is passed around", so IDs alone are a weak way to catch duplicates.

requestdate

The one required timestamp. The spec calls for ISO 8601 with an offset, such as 2026-09-26T19:42:10-06:00, which reads as 7:42 p.m. at six hours behind UTC (Mountain Daylight Time). Your response-time reporting starts from this value, so it has to be right.

vehicle

Year, make and model are required; VIN, stock number, trim, odometer, colors, price and finance details are optional. The interest attribute says what the customer wants (buy, lease, sell, trade-in or test-drive), and status marks new or used. Watch the defaults: interest defaults to buy and status to new, so a used-car lead that leaves status out reads as a new-car lead.

A trade arrives as a second <vehicle> block, so check that your CRM files it in the trade fields. If a <price> comes through, your team should see it before anyone replies, because the shopper may have seen it too.

customer and contact

The contact block holds the name (first, middle and last, or one full name), email, phone and address. A phone can be typed voice, fax, cellphone or pager, carry a preferred time of day, and be flagged as the preferred contact. The customer block adds <timeframe> and <comments>.

vendor

The dealership receiving the lead: <vendorname>, an optional website and a contact. In a dealer group, a wrong vendor name is how a lead for one rooftop ends up in another store's queue.

provider

Optional, and the most important optional element. The spec describes it as the service provider "that originated the lead", with a name, the service (the product or form), a website, an email and a phone. Without it, your CRM cannot tell a KBB lead from a website lead.

How an ADF email lead gets to your CRM

1. A shopper submits a form, chat or offer request on a provider's site.
2. The provider builds an ADF document from the form fields.
3. The provider emails it to the lead-intake address your CRM gave your store.
4. The CRM parses the XML, matches or creates the customer record, assigns the lead and fires its auto-response.
5. Any other system that needs the lead gets a copy (see the forwarding section below).

The spec allows two ways to send it: a multipart email with an application/xml part holding the lead plus an optional human-readable version, or a plain email whose entire body is the ADF lead with "no additional commentary". The spec warns that the plain method does not support UTF-8, so a name like José can arrive garbled.

If a lead cannot be accepted, the spec says the email should bounce back to the sender with an error note. Do not assume that happens. Ask your CRM who is notified when an ADF email fails to parse.

Why the provider field decides the first text

The source tells you what the shopper just did, and the first reply should prove you know it. A Kelley Blue Book Instant Cash Offer shopper is thinking about a trade. A CarGurus shopper asking about a specific car wants to know it is there. A website price-form shopper wants a number, which is a conversation for a person.

That is why source-aware follow-up starts with the ADF provider field. DealFlo's AI, Riley, for example, reads the lead source (KBB, CarGurus, AutoTrader, Cars.com, dealer website, lease-end, dead lead, service, past buyer) and opens differently for each. KBB lead follow-up works one source in depth.

Source data breaks in predictable ways. Provider names are free text, so one website vendor can send "Dealer Inspire" on one form and "Dealer Inspire - Get E-Price" on another, and a lead re-sent by another system may carry that system's name. Keep a mapping table from raw provider names to your lead sources, and review anything filed as "general" or "unknown" every week.

Common ADF problems and how to fix them

Missing or unusable phone numbers

ADF requires only a phone or an email, so email-only leads are valid. The spec's default phone type is voice, so a number marked voice may be a cell, and one marked cellphone may not be. Reply by email right away, ask for the best number to text, and check the line type before texting.

Duplicates

The same shopper submits on two sites, a provider resends, or one email reaches the CRM by two routes. Match on a normalized phone number (+1 and ten digits) and email before creating a record, treat status="resend" as an update, and keep the provider's <id> to trace each copy.

Wrong or messy provider names

Use the mapping table above, and watch for leads whose source appears only in the <service> line or the <id> source attribute. A parser that reads one field will file them as unknown.

Plain-text leads that are not ADF

Some providers send a formatted email, not XML. Others send ADF that gets mangled on the way, when an email client strips the tags or a manual forward adds "From:" and "Sent:" lines above the XML. Parsers then guess, and fields land in the wrong places. Ask every provider for ADF/XML delivery, and move leads with server rules, not by hand.

Broken XML

One character can break a lead. An ampersand in a dealer name like "Smith & Sons Motors" must be written as &amp;, the XML declaration can only appear at the very start of the document, and attribute values must sit in straight quotes (XML 1.0). Even the ADF 1.0 spec's own examples contain curly quotation marks, so do not copy them blindly.

Time zone errors

The request date should carry an offset. A feed that sends local time without one, or a UTC time that gets read as local, shifts the lead by hours and skews response-time reports and after-hours rules. Store timestamps in UTC, display them in the store's time zone, and spot-check a few against the time the email arrived.

How to forward ADF leads to a second system without breaking your CRM

An AI follow-up tool, call tracking, an outsourced BDC or group reporting may all need the same leads. There are three clean ways to give them a copy:

1. Add a second delivery address at each provider. The provider sends identical ADF to your CRM and the second system. It is the cleanest copy, but every provider has to be updated, and new ones get missed.
2. Use a mail-server rule or distribution group. Providers send to one store-owned address, and a server-side rule delivers an unmodified copy to the CRM intake address and the second system. It covers every provider at once, but someone in IT has to own it.
3. Use your CRM's lead forwarding, if it has it. Check a sample first: a re-generated lead may carry the CRM's name instead of the original provider's.

Whichever route you pick, protect the CRM with four rules:

• One system of record. The CRM owns the lead; the second system updates that record and never creates a new one from its copy.
• No loops. The second system never sends ADF back to the CRM intake address, or every lead becomes two.
• No manual forwarding. Hitting Forward changes the email and can break the XML.
• Test end to end. Submit a test lead from each provider and confirm exactly one CRM record, with the second system's activity on it.

DealFlo, for example, takes a forwarded copy of the ADF feed from any CRM while the CRM stays the system of record. The CRM pages for VinSolutions, eLead, DealerSocket and CDK cover the specifics.

ADF troubleshooting checklist

When leads go missing, arrive late or land in the wrong place, work down this list:

1. Confirm each provider's delivery address matches your CRM's current intake address.
2. Submit a test lead from each provider and time it from submit to CRM record.
3. Open the raw email. Is it XML, and does the <?xml declaration come first with nothing above it?
4. Run the XML through a validator and look for unescaped ampersands, curly quotes and unclosed tags.
5. Check that requestdate has an offset and matches the time the email arrived.
6. Check that the provider name maps to the right source in the CRM and in your reports.
7. Check the name, phone, email and comments all arrived complete and in the right fields.
8. Check that the trade landed in the trade fields and that new or used is correct.
9. Submit the same test lead twice and confirm it updates one record instead of creating two.
10. Confirm the auto-response fired and fit the source.
11. If a second system gets a copy, confirm there is still exactly one CRM record.

Once leads arrive clean, speed is the next lever; the lead response time guide covers the first minutes.

Frequently asked questions