Data brokers in the dealership stack: who is actually sending you the file

A dealership data aggregator is a third party holding a dealer's written authorisation to extract data from that dealer's system of record and deliver it onward to software vendors. It is neither the source system nor you. Most of what surprises a build later comes from two facts: the dealer signs the authorisation, and the columns you receive are the provider's interpretation of the source tables.

The layer exists because building against each system vendor separately is expensive on both sides. The source may be a system such as CDK, Reynolds and Reynolds, Tekion, Dealertrack or PBS, and the provider's job is to make all of them look alike. One schema across many stores is worth paying for. The cost is that fidelity, latency and recourse become properties of the provider rather than of the dealership.

Who is in the chain, and what each party actually controls

What the middle layer adds

• One integration instead of many. A group running 3 different systems across 12 rooftops becomes one schema, which is often the difference between onboarding a store in 5 working days and not being able to sell to the group at all.
• Normalisation. Dates, codes and names arrive in a single vocabulary, so your model is not re-litigated per store.
• Delivery you do not operate. An SFTP drop, an S3 bucket or a REST endpoint, with retries and a support desk that answers during business hours.
• Per-dealer permissioning. The underrated one: it turns adding a store into a request rather than a project.

What it removes, and why you find out late

• Fidelity. Normalisation is lossy by construction. A source carrying 11 order states mapped onto a target model carrying 5 is a decision somebody made once, and you inherit it — the same class of problem as stored codes that do not match what the tool showed.
• Identity. The provider may re-key as well as re-shape, presenting one object where the source held a header and its lines. Identifiers that were never stable get another layer of translation on top, which is why four times a repair-order number changes matters more here, not less.
• Absence. These feeds are usually snapshots, so a record deleted at the store stops arriving and nothing announces it — worked through in the deal was voided and it is still open in your app.
• Recourse. You hold no contract with the system vendor. A defect travels dealer to provider to vendor and back, and you are not on that thread. Budget 5 to 10 working days for a round trip, not hours.

What the layer emphatically does not fix is the store's own data model. A merged customer object assembled from two source systems still holds whatever the store put there, so the DMS and the CRM each believe they own the customer survives normalisation intact.

The authorisation chain, and who can end it

1. Get the authorisation in writing, naming your product as the recipient. A general authorisation held by the provider is not the same as one that covers you.
2. List the objects and fields it covers, and whether each is read or write. Scope creep in the other direction is common: you asked for four objects and were entitled to two.
3. Ask what notice you get on revocation — 30 days is worth asking for and rarely offered — and what happens to data already delivered. Both answers belong in the integration notes.
4. Confirm the dealer can point the same authorisation at a different provider without your rebuild. If it cannot, the switching cost is yours and you should price the risk into scope.
5. Record who signed and when. Dealer principals and general managers change, and the renewal conversation goes badly when nobody can name the original signer.

You do not have a data source. You have somebody else's contract, which you are allowed to read the output of.

Whether to take this path at all has its own criteria, argued in take the aggregator's feed or go to the vendor directly, and the vendor-run alternative is defined in certified DMS integration programmes explained. The question underneath both — does a dealership own the data in its system — is worth settling before anybody signs.

Standing up the pipeline, the reconciliation and the internal screens that sit on a third-party feed is work we scope under internal tools and ops. The rest of this silo sits under DMS, CRM and shop-system integration, inside our automotive work.

• dms integration
• data access
• vendor management
• dealership data