What Is ADF XML?

The small XML file that carries a car shopper from a lead provider into a dealership CRM, and what it looks like when it arrives broken.

ADF stands for Auto-Lead Data Format. It is an XML document with an agreed structure for one car shopper: who they are, how to reach them, which vehicle they asked about, which vehicle they might trade, what they typed in the comment box, and which vendor sent it. When somebody at a store says a lead came in as ADF, they mean a machine readable file arrived and became a record without anyone retyping it.

The format survives for an unglamorous reason. Almost every lead provider can produce it, almost every automotive CRM can read it, and it travels by email, which means two companies that have never spoken can exchange leads with no keys, no credentials and no integration project. A provider sends a message to an address and a lead appears in a CRM. That is a low bar, and it is exactly why the format became the common language of the business.

An ADF document wraps everything in a prospect element with a request date, and inside it sit four groups a salesperson would recognize:

• Vehicle: year, make, model, trim, VIN, stock number, and two attributes that matter more than any of them, interest (buy, lease, trade in) and status (new, used, certified).
• Customer: the contact name, email address, phone numbers with a type on each, the mailing address, and a comments block holding whatever the shopper typed.
• Trade: an optional second vehicle with mileage and condition, when the form asked about one.
• Vendor and provider: which store the lead is for and which service sent it, which is what a CRM turns into the lead source.

Nothing in that list is exotic, and that is the point. A well formed ADF is a lead you could read out loud. The trouble is never the structure, it is what people put inside the fields.

Leave your number and a lead specialist calls you back to answer your questions about pricing, coverage, and setup. Mon - Sat, 9:00 AM - 6:00 PM Pacific.

Prefer to talk right now? Call or text 844-376-2274.

A worked example, illustrative only. A store buys leads from a provider and gives it a dedicated intake address. At 7:12 a shopper submits a form asking about a used crew cab listed at $38,900. The provider builds an ADF with the shopper's name, a mobile number, an email, the VIN and stock number of that truck, status used, interest buy, a trade with 96,000 miles, and a comment asking whether the price is firm. It emails the file to the intake address.

The CRM reads the message, parses the XML, creates a lead with the source set to that provider, attaches the VIN so the salesperson opens the record already knowing which unit is in play, and routes it to whoever owns that feed. Total elapsed time is seconds. The salesperson sees a truck, a trade, a question about price and a phone number, which is a far better starting point than a name and the word inquiry.

Four failures account for nearly all of it, and every one of them is worth checking before blaming a CRM.

The first is a vehicle expressed as one free text string instead of separate fields, something like the word Certified followed by a model year, a make, a model and a mileage figure all run together. A careless parser splits on spaces and decides the make is Certified and the model is a four digit number. Those records look plausible, pollute source reporting and break duplicate detection, which is worse than an obvious error.

The second is delivery dressed up as marketing: the file arrives as an attachment beside an HTML message with a logo and a footer, and a strict parser on the other end takes the message as text and finds nothing. The third is a sender that emails twice for every lead, once for a human and once for a parser, so the receiving system creates two records and the store blames its CRM for a problem made upstream. The fourth is plain email authentication. If the sending domain is not aligned, the message is discarded before any parser sees it, and nobody is told. The buying side of all four is covered on automotive CRM with ADF and XML integration.

LeadLocate CRM reads ADF in both directions. Inbound documents arrive through custom source feeds set up in Lead Feeds Manager, where each provider gets its own delivery route, so the source is established by how the lead arrived rather than by a salesperson picking from a dropdown an hour later. A genuine ADF document is parsed by structure, field by field, and anything that is not valid XML falls back to careful reading rather than being discarded, which is what saves the plain text and HTML table leads smaller vendors still send. Outbound, a lead can be pushed as a clean ADF document to the intake address of whatever CRM a store keeps for franchise reasons, every push logged so the question of whether a lead ever arrived has an answer. The wider tool set around it sits in LeadLocate CRM.

ADF is excellent at moving a lead between two companies that have no relationship, and poor at anything live or two way. Use it for lead providers, marketplaces and manufacturer programs. Use a posted webhook when the other side is your own website or a partner with a developer, because the record appears immediately instead of waiting on mail delivery. Use a CSV upload for a list you bought or exported once, such as a show list or a service file.

The same distinction shows up further along the deal. Moving a finished credit application to a lender or into a dealer management system is a different job with different formats, described on lender and DMS export formats. ADF moves shoppers. It was never meant to move deals, and a store that tries to make it do both ends up with neither.

Is ADF the same thing as XML?

No. XML is a general way to structure data. ADF is one specific XML vocabulary for automotive leads, with defined elements for the prospect, the vehicle, the customer and the vendor.

How is an ADF lead delivered to a dealership?

Almost always by email to a dedicated intake address, which is why it works between companies with no shared credentials. Some providers can post the same document to a web address instead.

Why did a lead arrive with the make listed as Certified?

Because the provider packed the whole vehicle description into one free text field and the receiving parser split it on spaces. It is a parsing problem, not a data problem, and a careful parser reads the string properly.

Can leads be sent out as ADF as well as received?

Yes. A lead can be pushed as a clean ADF document to the intake address of another CRM, which is how a store keeps a required system fed while it works leads somewhere else.

Bring a real document from each provider you use. A specialist runs it through a feed on a live account so you can see every field where it lands.

Prefer to talk right now? Call or text 844-376-2274.