What is a Dealer Management System (DMS)?

A Dealer Management System is the operational platform that runs a franchised dealership or dealer group. It holds the canonical record of vehicle stock (new, used, and forecourt), pricing and discount structures, finance and insurance products, customer accounts, service-and-parts operations, accounting integration, and the workflows that move a vehicle from order through PDI to delivery. In a typical UK dealer group, the DMS is the source of truth for everything that touches a sale, and any other system — ecommerce, CRM, marketing — reads from it or writes back to it.

Which DMS vendors operate in the UK market?

The major UK DMS vendors are Keyloop (the merged entity that absorbed CDK International, Drive, and parts of the Reynolds & Reynolds estate), CDK Global (still a major US-headquartered presence in UK retail), Pinewood Technologies (Pinnacle, popular with mid-size and premium franchises), Auto Trader Connect (positioning into the DMS-adjacent layer), and a long tail of specialist or modular providers including Tracker Plus, Procon, Dealerweb, Connectit, and Saunders & Co. Most dealer groups run one primary DMS across their franchises, with secondary systems for specific functions like reservations or appointment booking.

What does it mean to integrate a DMS with ecommerce?

DMS-to-ecommerce integration means the customer-facing website or storefront pulls live data from the DMS rather than maintaining its own copy. At minimum this covers vehicle stock and pricing — when a vehicle sells in the showroom, the website reflects that within minutes rather than hours. At its fullest, it covers reservations (the website can hold a vehicle in DMS), F&I quotations (the website can produce a regulated finance quote that matches what F&I would produce in branch), and customer record write-back (the website creates leads or contacts that flow into CRM/DMS without re-keying).

What is the difference between API integration and batch sync?

Real-time API integration means the ecommerce system queries the DMS on demand or subscribes to events, with data freshness measured in seconds. Batch sync means the DMS exports a flat file (CSV, XML, or feed) on a schedule — typically nightly — and the ecommerce system imports it, with data freshness measured in hours. API integration is more accurate but more expensive to build and maintain, and requires the DMS vendor to expose suitable endpoints. Batch sync is cheap, well-understood, and works for stock data, but cannot support reservations, real-time pricing changes, or F&I quotations that require a live calculation.

Why do DMS integrations fail in practice?

Five recurring failure modes. Stale stock — the website shows vehicles that have already sold because the sync interval is too long. Dual-write conflicts — both the DMS and the ecommerce system try to own the same record (typically customer or reservation) and they disagree. FCA-regulated finance flows — the finance quotation produced online does not match the in-branch quotation, creating compliance and trust issues. Identity reconciliation — a customer who registers online and walks into the dealership is treated as two different people. Image source-of-truth drift — the DMS holds one set of vehicle photographs, the ecommerce system holds another, and they slowly diverge. Each of these is solvable; together they explain most disappointing integrations.

Should we integrate our DMS or replatform onto a DMS-native commerce layer?

It depends on how much of the customer journey runs online. If the website is a lead-generation surface and most transactions complete in branch, a stock-and-pricing integration is enough. If a meaningful percentage of customers are reserving vehicles, applying for finance, or completing online — what the UK market is moving towards — the integration surface area expands quickly, and the operational cost of stitching disparate systems together starts to rival the cost of replatforming. The answer is not the same for every dealer group. It depends on volume, the journey roadmap, and the strategic value placed on owning the front-end versus accepting the vendor's roadmap.

How long does a serious DMS-to-ecommerce integration take to build?

A first-cut stock-and-pricing integration is typically delivered in six to twelve weeks of focused engineering, depending on the vendor's API maturity and how clean the data is in the DMS. A full integration covering reservations, F&I quotation, and customer write-back is realistically six to nine months of work, including discovery, integration design, FCA-compliance review for finance flows, testing across edge cases (multi-franchise rules, demo vehicles, manager specials), and a careful rollout. The variable is rarely the engineering — it is the data quality in the DMS and the willingness of the vendor to support the integration shape you want.

What should a UK dealer group integrating with a DMS in 2026 actually use?

Use the DMS vendor's documented APIs where they exist, even if they are limited — fighting the vendor's roadmap is a losing strategy. Treat the DMS as the system of record for stock, pricing, F&I, reservations, and operational customer data. Run a thin integration layer (a bespoke service or a managed iPaaS like Workato or Boomi) that reconciles identity across DMS, CRM, and ecommerce, owns the rules for which system writes which field, and exposes a clean API to the ecommerce front-end. Keep the ecommerce front-end as a presentation layer that does not own canonical data. This pattern survives DMS swap-outs, ecommerce replatforms, and CRM changes — anything else creates lock-in to a specific vendor combination.

Dealer Management Systems: Integrating DMS with Your Ecommerce Stack

A franchised dealer group rebuilds its consumer website. The new front-end is fast, well-designed, and tracking conversion lifts. Three months in, sales staff start ignoring the leads it produces. The reason is not the website. The reason is that the website does not know the same things the dealership knows. The price on the page is yesterday’s price. The vehicle on the page sold in the showroom this morning. The finance quote the customer saw online is not the finance quote the F&I manager can actually offer. The customer who registered online walks in and is treated as a stranger.

This is the gap between a website and an integrated retail system. In automotive retail, the system that closes that gap is the Dealer Management System — and integrating with it well is the work that separates a marketing site from a digital retail platform. This guide covers how UK franchised dealer groups should think about that integration in 2026.

What a DMS Actually Does

A Dealer Management System is the operational backbone of a dealership. In a UK franchised group, the DMS holds the canonical state of:

Vehicle stock. New, used, demonstration, courtesy — every vehicle on the books with VIN, mileage, location, derivative, options, and status (available, reserved, sold, in-PDI, in-transit).
Pricing. List price, on-the-road price, manufacturer offers, dealer discounts, special offers, multi-vehicle discounts, end-of-quarter retail promotions. Pricing in automotive retail is dynamic and rule-driven, not static.
Finance and Insurance (F&I). Approved finance products, lender panels, APR calculation engines, GAP and tyre insurance, service plans, the underlying compliance rules, and the workflows for producing an FCA-compliant quotation.
Reservations and orders. The state machine that moves a vehicle from “available” through “reserved”, “deposit paid”, “sold subject to PDI”, and “delivered”. Each state has business rules attached.
Customer records. Existing customer accounts, vehicle ownership history, service history, marketing consents.
Service and parts. Service department workflows, parts inventory, technician scheduling. Less relevant to ecommerce integration but heavily integrated with everything else.
Accounting. General ledger integration, daily reconciliation, manufacturer claims and bonuses.

A DMS is not a CRM, even though it holds customer records. It is not a marketing platform. It is not an ecommerce engine. It is the operational system of record, and any other system that touches the dealership ultimately reads from it or writes back to it.

The Major UK DMS Vendors

The UK DMS market has consolidated significantly over the last decade. The current shape:

Keyloop. The merged entity created from CDK International’s UK and European business, Drive (formerly CDK Drive), and parts of the Reynolds & Reynolds heritage estate. Keyloop is the dominant DMS provider across UK franchised retail, with deep penetration in volume franchises. The product portfolio includes Drive, Autoline (older but still in active deployment), Autoline Rev8, and a growing layer of vendor-managed digital products around the core DMS.

CDK Global. The US-headquartered parent that retains a major UK presence in retail. The split between CDK Global and Keyloop creates some confusion in the market — they are separate businesses with overlapping heritage.

Pinewood Technologies (Pinnacle). The choice for many premium and mid-size dealer groups, particularly where the franchise mix favours JLR, BMW, and German premium brands. Pinnacle has a reputation for strong reporting and modular architecture.

Auto Trader Connect. Auto Trader has been pushing into the DMS-adjacent layer for several years, integrating stock, pricing, and lead-management capabilities. Whether you classify Auto Trader Connect as a DMS depends on how strictly you define the term — it does some DMS-like work but sits alongside a primary DMS in most groups.

Specialist and modular vendors. Tracker Plus, Procon, Dealerweb, Connectit, Saunders & Co. These are smaller players, often serving independent dealers, specialist franchises, or the long tail of niche operators. They matter to ecommerce integration because a dealer group acquired through M&A will sometimes inherit one of these systems and need to integrate it alongside the primary DMS.

The practical reality is that most UK dealer groups run one primary DMS across their franchises — typically Keyloop or Pinnacle — with one or two secondary systems for specific functions. Integration architecture should be designed around that primary, with a clear strategy for the secondaries.

The Integration Patterns

There are four shapes a DMS-to-ecommerce integration can take. Each has trade-offs that matter.

Real-time API integration

The ecommerce front-end calls the DMS API on demand. Stock is read live, pricing is read live, reservations write live. This is the modern pattern and the one most vendor roadmaps are pointed at. The strengths are obvious: data freshness measured in seconds, support for live transactions, the ability to do things like “hold this vehicle for fifteen minutes while the customer completes checkout”.

The weakness is that the integration is only as good as the API. Where the DMS vendor exposes a mature, well-documented REST or GraphQL API with sensible rate limits, real-time integration is straightforward. Where the API is partial, slow, or behind a per-call commercial model, the integration becomes a long negotiation about which calls are economically viable and which need to be cached.

Batch nightly sync

The DMS exports a flat file — CSV, XML, occasionally JSON — on a schedule. Typically nightly, sometimes hourly. The ecommerce system imports the file and rebuilds its catalogue. This is the legacy pattern, the one that ran most UK dealer websites for the last fifteen years.

It works well for stock and pricing as long as you accept hour-level latency. It does not work for reservations, real-time pricing changes, or F&I quotations that require a live calculation. Most modern integrations use batch sync as a fallback or initialisation mechanism — the website backfills from a nightly file and uses the API for live state — rather than as the primary pattern.

Message-bus / event-driven

The DMS publishes events to a message bus or webhook stream — vehicle reserved, price changed, customer updated — and downstream systems subscribe. This is the architecturally cleanest pattern and the one engineers ask for first. It is also rare in UK automotive retail because most DMS vendors do not yet expose a clean event stream as a first-class product. Where it exists, it tends to be a derivative of a logging or replication mechanism rather than a designed event API.

When it does exist, it is excellent. When it does not, attempting to retrofit one over a legacy DMS is a long road that usually ends with either a paid vendor service or a bespoke integration layer that polls the DMS API and emits events itself.

Iframe / hosted page

The DMS vendor offers a hosted finance calculator, reservation flow, or stock list that the dealer’s website embeds as an iframe. This is the worst pattern. The hosted page is rarely well-designed, rarely matches the brand, rarely works on mobile, and locks the dealer into the vendor’s product roadmap. It is sometimes the right choice for FCA-regulated flows where the vendor takes on compliance liability, but otherwise it should be avoided.

The Seven Endpoints That Matter

Across hundreds of integration projects in UK automotive retail, seven endpoint types determine whether a DMS-to-ecommerce integration is genuinely useful or merely cosmetic. Most failed integrations cover three or four of these well and the rest badly.

1. Vehicle stock. Live availability of every vehicle with VIN, derivative, mileage, options, location, and status. The bare minimum. Without this, the website is a brochure.

2. Pricing. Current OTR price, with the rules-engine output already applied — manufacturer offers, dealer discounts, multi-vehicle bundles, end-of-quarter promotions. Pricing in UK automotive is rarely a single number; it is the output of a calculation that runs against a dozen rules.

3. F&I quotation. A live finance quote that matches what the F&I manager would produce in branch. This is the highest-stakes endpoint because it carries FCA compliance weight. An online quote that diverges from the in-branch quote is not a UX problem — it is a regulatory problem.

4. Reservation / hold. The ability to mark a vehicle as held in DMS for a customer who is mid-checkout. Essential for any ecommerce flow that goes beyond enquiry. Usually requires the vendor to expose a state-changing API endpoint, which not all do.

5. Customer record write-back. A customer who registers, enquires, or transacts online creates a record that flows into DMS and CRM without re-keying. This is the endpoint that most often fails — most dealer groups end up with a website that produces leads as raw email and a sales team that re-keys them into DMS by hand.

6. Valuation and part-exchange. Either a vendor-provided valuation engine (CAP HPI, Glass’s, Auto Trader, Cazana) integrated through the DMS, or a direct integration that bypasses the DMS. The integration question is which side of the ecosystem owns the part-exchange offer and how it flows into the eventual deal record.

7. Finance application. The submission of a regulated finance application to a lender panel, with the response and decision flowing back. This is the deepest end of the integration spectrum and the one that turns a website into a true digital retail surface.

A useful sequencing of an integration programme is: stock and pricing first, customer write-back second, F&I quotation third, reservations fourth, valuation and finance application as a final phase. Most groups attempting all seven simultaneously underestimate the complexity and end up with a partial integration in every dimension.

Common Integration Pitfalls

Five patterns that undermine DMS-to-ecommerce integrations in UK automotive retail. None are technical novelties; all are operationally common.

Stale stock. The website shows a vehicle that sold in the showroom an hour ago. The customer arrives or calls and is told the vehicle is gone. Trust drops, conversion drops, complaints rise. The fix is not just shorter sync intervals — it is event-driven invalidation. When a vehicle’s status changes in DMS, the website must know within seconds, not hours.

Dual-write conflicts. The website writes a customer record, the DMS writes a customer record, and within a few weeks the same human exists as three records across the systems. The fix is a clear policy on which system owns which fields, enforced through an integration layer rather than left to ad-hoc rules. In most architectures, DMS owns the canonical customer; the website creates leads that the DMS converts into customers; the CRM reads from both and reconciles.

FCA-compliance issues with finance APIs. The finance quote produced online uses a different rate, different APR, or different term assumptions than the in-branch quote. The quote is reproduced verbatim by a customer and the dealership cannot honour it. This is a regulatory issue under FCA consumer credit rules and a trust-destroying customer experience. The fix is a single source of truth for finance calculation — usually the DMS or vendor F&I engine — called by both the in-branch and online flows. Anything that produces finance numbers on the front-end without going through that source is a compliance risk.

Identity reconciliation across DMS, ecommerce, and CRM. A customer registers on the website with one email, walks into the dealership and gives a different email, and is treated as two different people. The customer who has visited the website three times this week is invisible to the salesperson who picks up the phone. The fix is an identity layer — sometimes a feature of the CRM, sometimes a bespoke integration service — that resolves customers across systems by phone, email, and (where consent allows) name and postcode.

Image source-of-truth drift. The DMS holds one set of vehicle photographs (often from the manufacturer’s master image library or from forecourt photography). The ecommerce system holds another set (often from a third-party imaging service like CitNOW or AutosOnShow). They slowly diverge. The vehicle photo on the website does not match the vehicle, or shows a previous customer’s specification. The fix is a single source of truth for vehicle imagery, typically the third-party imaging service, with both DMS and ecommerce reading from it rather than from each other.

A Decision Framework: Integrate or Replatform

The biggest strategic question in DMS-to-ecommerce architecture is not how to integrate, but whether to integrate at all versus replatforming the front-end onto the DMS vendor’s commerce layer. Keyloop, CDK, and Pinewood all offer some flavour of vendor-native commerce surface. Auto Trader Connect is positioning into adjacent territory.

The trade-off is real. Vendor-native commerce comes with the integration already done — stock, pricing, reservations, F&I — but ties the front-end to the vendor’s roadmap, design language, and release cadence. Independent ecommerce gives full control of the customer experience but takes on the integration cost.

The decision rests on three questions:

How much of the customer journey runs online? If the website is primarily a lead-generation surface and most transactions complete in branch, the integration surface is small and bespoke ecommerce is straightforward. If a meaningful share of customers reserve, finance, or complete online — what the UK market is steadily moving towards — the integration surface expands and vendor-native starts to look more efficient.

How much does the brand differentiate at the front-end? Premium franchises and dealer groups whose competitive edge is brand experience and customer journey design typically need more control than vendor-native offers. Volume franchises competing on price and inventory often do not.

How long is the planning horizon? Vendor-native commerce can be deployed in months. Independent ecommerce with full integration is a year-plus programme. For groups that need to ship something in 2026 and have time to evolve, vendor-native is a reasonable starting point. For groups planning a five-year digital strategy, independent ecommerce with a thin integration layer is usually the better foundation — it survives DMS swap-outs and vendor changes that vendor-native does not.

There is also a hybrid pattern that many UK groups land on: vendor-native or vendor-hosted for the FCA-regulated finance flows, where the compliance liability is meaningful, and independent ecommerce for everything upstream. This trades some UX consistency for reduced compliance overhead and is a reasonable middle ground.

For groups taking the integration route seriously, this is genuinely platform engineering services work — identity reconciliation, integration layers, event-driven architecture, and the rest of the discipline that turns disparate systems into a coherent retail platform.

If You Are Starting in 2026

For a UK dealer group designing the architecture of a digital retail platform from scratch in 2026, the recommended shape:

1. Treat the DMS as the system of record. Stock, pricing, reservations, F&I, customer operational data — owned by the DMS, written nowhere else. Resist the temptation to build a parallel catalogue in the ecommerce system. The catalogue will drift within months and the dealership will stop trusting whichever system shows more recent data.

2. Build a thin integration layer. A bespoke service, or a managed iPaaS like Workato, Boomi, or MuleSoft, sitting between the DMS and the consumer-facing systems. The integration layer owns the rules for which system writes which field, the identity reconciliation logic, and a clean API surface for the front-end. This pattern survives DMS swap-outs and ecommerce replatforms — anything that bakes vendor-specific assumptions into the front-end creates lock-in.

3. Use the DMS vendor’s APIs where they exist, even if limited. Fighting the vendor’s roadmap is a losing strategy. Where Keyloop or Pinnacle expose a documented endpoint, use it; where they do not, lobby for it; where they refuse, build an adapter rather than a workaround. The vendors are slowly converging on more open APIs and the long-term direction favours integrators that work with the grain.

4. Keep the ecommerce front-end as a presentation layer. The website should not own canonical data. It should consume from the integration layer and render. This makes the front-end replaceable — Shopify Hydrogen this year, Next.js Commerce next year, headless CMS with custom front-end the year after — without disrupting the underlying retail platform. For more on this pattern, see our composable commerce explained guide.

5. Plan F&I integration carefully. The F&I endpoint is the highest-stakes integration in the platform. A live finance calculator on the website that diverges from the in-branch calculator is a compliance issue under FCA consumer credit rules and a customer-experience disaster. The realistic options are: use the vendor’s hosted F&I flow (taking on their UX in exchange for compliance liability), or integrate the vendor’s F&I calculation engine through API and own the front-end (taking on the integration cost in exchange for control). Avoid building your own finance calculator that approximates the DMS engine — the divergence will catch up with you.

6. Use AI selectively where it earns its place. Pricing optimisation, demand forecasting, F&I product recommendation, customer-intent scoring — these are reasonable applications for AI and data services once the integration foundation is solid. Building AI on top of stale or fragmented DMS data produces unreliable models that erode trust in both the AI and the integration. Get the data right first.

7. Treat DMS replacement as a legacy modernisation programme, not an upgrade. Some UK dealer groups will spend the next three years moving off legacy DMS instances onto current-generation platforms. This is genuine legacy modernisation work — co-existence patterns, careful data migration, dual-running periods, identity reconciliation across old and new systems. It is not a swap-out and rarely a project that completes in the timescales the vendor’s salesperson promises. For the broader pattern, our legacy modernisation guide covers the architecture moves that keep these programmes deliverable.

8. Make the DMS choice strategic, not tactical. The DMS is the foundation of the digital retail platform for the next ten years. The choice deserves the same scrutiny as the ERP choice in a non-automotive business. Frame it as a digital strategy decision rather than an IT procurement, and bring senior business stakeholders into the evaluation. The vendor’s roadmap, openness, and willingness to invest in the integration ecosystem matter more than the feature set today — the feature set today will be replaced; the relationship will not.

Getting Help

We have integrated with most of the major UK DMS vendors across franchised retail. The patterns above are drawn from work in the trenches — including Vanarama’s growth from £20m to £200m, where the digital retail platform was built around exactly the integration questions in this guide.

If you are evaluating a DMS, designing an integration architecture, or replatforming an ecommerce front-end onto an existing DMS estate, get in touch. For broader context on the platform decisions that surround DMS choice, our composable commerce explained and legacy modernisation guide cover adjacent ground.