Automotive CRM With ADF and XML Integration

The format the whole industry runs on, handled properly in both directions rather than pasted into a note field.

ADF stands for Auto-Lead Data Format. It is an XML document with a defined structure for a car shopper: who they are, how to reach them, which vehicle they asked about, which vehicle they might trade, and which vendor sent it. It has been the common language of automotive lead delivery for a very long time, and it is not going anywhere.

The reason it survives is unglamorous. Almost every lead provider can produce it, almost every automotive CRM can consume it, and it travels by email, which means it works between two companies that have never spoken to each other and have no shared credentials. No API keys, no integration project, no vendor negotiation. A provider sends a message to an address and a lead appears in a CRM.

That simplicity is also the problem. Because it moves by email and because the format has been extended informally for two decades, what arrives at your store is frequently not valid ADF. It is HTML dressed as XML, or a plain text email with the fields rearranged, or a valid document with the whole vehicle description crammed into a single element. Systems that assume clean input either drop those leads or mangle them, and the store finds out three weeks later when a customer mentions they submitted twice.

When a vendor says they support ADF, ask which direction, because they are separate pieces of engineering and stores need both.

Inbound. A third party provider, a marketplace, your website vendor or a manufacturer program sends you a lead as ADF and it has to become a real record in your system, correctly parsed, correctly attributed to that source, and routed to a person.

Outbound. You have a lead in one system and it needs to arrive in another. This is the direction that matters if you keep an existing CRM for franchise or manufacturer reasons and want lead flow from somewhere else to land in it. It is also what makes a parallel run possible during a change, since both systems can be fed the same leads while you evaluate.

We built both, and the outbound side is the one dealers are usually surprised to hear about, because vendors generally prefer that your leads have no route out of their platform.

Inbound lead documents arrive through custom source feeds. Each feed has its own delivery route, which means the source is established by how the lead arrived rather than by a salesperson choosing from a dropdown forty minutes later. That single design decision is why source reporting downstream is worth reading, and it is covered in more depth on the lead source dashboard page.

The parsing pipeline runs in two stages. First a strict ADF parse. If the document is genuinely an ADF document with a prospect element, the fields come out by structure, which is precise and fast and preserves the semantics that matter: the customer, the requested vehicle, the VIN, the interest, the status, the provider.

If the document is not valid ADF, the pipeline falls back to intelligent parsing rather than discarding the lead. That covers the plain text emails, the HTML tables and the odd formats that smaller providers still send. Raw content is preserved for the structured formats so nothing is lost in the handoff, and attachments are handled rather than ignored, since a meaningful share of providers attach the ADF rather than putting it in the body.

The practical outcome is that a feed you would otherwise have to work by hand becomes a routed lead with a source on it. A store adding a new provider does not need an integration project, a developer, or a phone call between two vendors. They need a delivery address.

The outbound side sends a lead as a proper ADF 1.0 document to an address you specify, which in most stores is the intake address of an existing CRM.

Every path that can create a lead uses the same push mechanism rather than each having its own slightly different version. A rep pressing push on a lead record, a team notification, an inbound webhook, a website form, an inbound email or text that produced a lead, a self generated website form, and custom source feeds all produce the same document. That consistency sounds like an implementation detail until you have lived through the alternative, where six code paths each send a slightly different email and a strict parser on the other end accepts three of them.

Every push is logged, so there is an audit trail showing what was sent, when, for which lead, and by which route. When somebody says a lead never arrived, that log answers it in seconds instead of becoming a standoff between two vendors.

Most automotive CRMs accept ADF by email. Confirm the intake address and the accepted format with your own CRM vendor before you rely on it, because their parsers differ and some are stricter than the specification requires.

Here is the detail that separates real ADF handling from a template with variables in it, and it is worth understanding before you evaluate anybody.

Leads frequently arrive with the vehicle expressed as one free text string. Something like New 2024 Honda Civic LX, or 2019 Ram Pickup 1500 Big Horn, 48,215 miles. A naive parser splits on spaces and assumes the first token is the year and the second is the make. Feed it a string beginning with New or Certified Pre-Owned and you get a lead whose make is New and whose model is 2024. Feed it a compound model name and the body style ends up wedged into the trim.

Those ghost records are corrosive because they look plausible. They pollute reporting, they break duplicate detection, and they make a salesperson open a record that says nothing useful about which car the customer asked for.

Our parser strips inventory status prefixes first, looks for the year anywhere near the front of the string rather than assuming position, checks the make against a known makes table using whole word matching so a trim like Sport or LT is never mistaken for a manufacturer, and extracts VIN, price and mileage separately. When it is not confident, it returns an empty field rather than a guess. That last rule is the important one. An empty field is honest. An invented one is a lie your team will act on.

This is the failure nobody warns you about. An ADF push that looks fine on your end can be quietly discarded by the receiving CRM, and neither vendor tells you.

Three causes account for most of it. The first is format. Strict parsers expect a plain text document and choke on a message dressed up with HTML or carrying the ADF as a decorative attachment alongside a marketing footer. Ours is sent as a pure text document per the specification rather than as a formatted email.

The second is duplication. A pushing system that sends two messages per lead, one for a human and one for the parser, produces duplicate records at the other end. Stores then blame the receiving CRM for a problem created upstream. One push produces one document.

The third is email authentication. If the sending domain does not align on SPF, DKIM and DMARC, the receiving side may drop the message before any parser sees it. The sender on our push is pinned to a properly aligned domain for exactly this reason. This is invisible plumbing and it is the difference between a feature that works and a feature that appears to work.

When you evaluate any vendor's ADF support, ask these three questions specifically. The answers tell you whether somebody built it or wrote it on a slide.

ADF is excellent at moving a lead between two companies. It is a poor fit for anything real time or two way, so it should not be the only route in.

Inbound webhooks handle sources that can post directly, which includes most modern website vendors and form tools. A posted lead becomes a record immediately rather than waiting on mail delivery, and it can trigger an outbound ADF push in the same moment if you also want it in another system. Website forms, chat conversations and inbound texts each create records through their own path, and every one of them can feed the push.

On the inventory side, My Inventory Link exposes a public inventory API with key provisioning, which is the right tool when a partner needs to read your vehicles rather than send you a lead.

The general rule: use webhooks or an API when both sides are yours or your partner is technical, and use ADF when you are dealing with a third party you will never have a technical conversation with. There is more on the programmatic side in CRM API integrations.

Some limits, because ADF support is regularly oversold.

This is not a certified integration with any specific CRM or manufacturer program. We are not an OEM certified CRM. If your franchise agreement specifies a CRM and a certified data path, ADF push does not satisfy that requirement and we would not pretend otherwise.

It is also not a DMS connection. ADF moves leads, not deals, not repair orders, not accounting. We are not a dealer management system and we do not sell one. If DMS connectivity is the actual requirement, read CRM with DMS integration for an honest account of what does and does not connect.

And it is not a substitute for duplicate management. Feeding two systems the same lead means both systems have it, which is the point during a parallel run and a nuisance afterward. Plan the cutover. Our page on duplicate lead management covers the hygiene side.

Do not take anybody's word for this, including ours. The test takes twenty minutes.

Send yourself a real ADF from each provider you use into a test feed and check that the customer, the vehicle, the VIN and the source all landed in the right fields. Then send the ugly ones deliberately: a document with the vehicle as one free text string, one beginning with Certified Pre-Owned, one with no vehicle at all, and one that is plain text rather than XML. Watch what each becomes. Then push a lead outbound to your other CRM and confirm on the receiving side that exactly one record appeared with the fields intact.

Any vendor that will not let you run that test with real documents before signing is asking for faith you have no reason to extend. Ours is available on the demo.

Pricing is month to month with no long term contract. CRM Only starts at $199 a month if you have your own lead sources and want the software, the feeds and the push. Plans that include exclusive territory leads start at $799, and combined buyer and seller programs start at $1,599. Current figures are on the pricing page.

Can you receive ADF leads from our existing providers?

Yes. Custom source feeds accept ADF and XML documents, and the pipeline tries a strict ADF parse first. Documents that are not valid ADF, including plain text and HTML formats, fall back to intelligent parsing rather than being discarded.

Can you push leads out to a CRM we already run?

Yes. Leads are pushed as spec clean ADF 1.0 to an address you specify, from a rep pressing push, from webhooks, from website forms, from inbound email or text, and from custom source feeds. Every push is logged for audit.

What happens to a vehicle description that arrives as one text string?

It is parsed conservatively. Inventory status prefixes such as New or Certified Pre-Owned are stripped, the year is found by pattern rather than position, the make is checked against a known makes table by whole word, and VIN, price and mileage are extracted separately. Uncertain fields are left empty rather than guessed.

Why do ADF emails sometimes get rejected by the receiving CRM?

Usually format, duplication or email authentication. Strict parsers expect a plain text document, they create duplicates when a system sends two messages per lead, and messages from a domain that does not align on SPF, DKIM and DMARC can be dropped before any parser sees them.

Is this a certified integration with our OEM's CRM program?

No. We are not an OEM certified CRM and ADF push does not satisfy a franchise requirement for a certified data path. Check what your agreement actually specifies before relying on it.

Can we run both CRMs at once while we evaluate?

Yes, and that is one of the better uses of outbound push. Feed both systems the same leads for a few weeks, compare response times and outcomes, then plan the cutover and turn one off rather than leaving duplicates running.

We will run real documents from your current providers through the parser, push one back out to the CRM you already keep, and show you the audit log. Month to month, no long term contract.