Fitment Data: The Part of Auto Parts Commerce Nobody Scopes

Fitment data is the part of auto parts e-commerce that teams consistently underestimate until they're three months into a build and realising the catalogue they licensed doesn't actually answer the question "will this part fit my car?"

What Fitment Data Actually Is

A part number tells you what something is. Fitment data tells you what vehicles it works on.

In practice that means maintaining a mapping between parts and Year/Make/Model/Engine (YMME) combinations, sometimes extended with sub-models, trim levels, drivetrain types, body styles, and position codes (front-left, rear-right, etc.). The industry standard for this is the ACES (Aftermarket Catalog Exchange Standard) format, maintained by the Auto Care Association. ACES is an XML schema. A typical ACES file for a mid-sized parts brand has tens of thousands of application records.

The parallel standard is PIES (Product Information Exchange Standard), which covers the product attributes side: dimensions, weights, pricing, digital assets. People often conflate the two. ACES is fitment. PIES is product. You need both.

Fitment data is not static. Manufacturers update it when they discover a part fits additional vehicles, or when they find it was incorrectly mapped. A catalogue you ingest today will be wrong in 90 days without a refresh pipeline.

Why Scoping Always Goes Wrong

Most product teams scope auto parts commerce the same way they scope general e-commerce. SKU, price, stock, image, description. That's the schema they plan. Fitment is treated as a filter, maybe a dropdown.

The problem surfaces at the data model level. A fitment application is a many-to-many relationship between a part and a vehicle configuration. That vehicle configuration is not a single table row. The VCdb (Vehicle Configuration Database), another Auto Care Association standard, contains over 800,000 distinct vehicle configurations once you account for all the attributes. A single part might have 2,000 application records. Multiply across 50,000 SKUs and you're into hundreds of millions of rows before you've written a line of business logic.

Search is the next problem. A user types "2019 Ford Ranger brake pads front." That query needs to resolve against YMME, position, and then filter by what's actually in stock and ships to their postcode. If you've built a standard text search pipeline, possibly using Elasticsearch or Typesense, the fitment join is not something those engines do natively. You're either denormalising at index time or doing a relational join after the fact. Both approaches have real latency implications.

Then there's the UX for vehicle selection. A year-make-model-submodel selector with cascading dropdowns sounds simple. Getting the data for it right is not. The 2019 Ford Ranger in North America and the 2019 Ford Ranger in Australia are different vehicles. If your catalogue mixes regions, you'll serve wrong fitment results.

What Does a Correct Fitment Architecture Look Like?

The Vehicle Selector and Garage

The vehicle selector is usually the first thing a user interacts with. Cascade it: Year → Make → Model → Engine/Trim. Each level queries only valid combinations from the VCdb, not a static list. If a user selects a year and make that has no entries in your active catalogue, surface that immediately rather than letting them reach zero results.

Storing the selected vehicle in a session-level "garage" (a list of saved vehicles per account) is standard. Most repeat buyers configure their garage once. Every subsequent visit should default to their vehicles. This dramatically improves conversion on return sessions.

The Application Database

The application records from ACES need to live in a relational store, not a document store. PostgreSQL handles this well. The core tables are: part, vehicle_config, application, and the VCdb attribute tables (make, model, year, engine base, sub-model, etc.).

Indexing strategy matters more than schema here. A query like "give me all parts that fit vehicle config 482901" needs an index on vehicle_config_id in the application table. A query like "give me all vehicle configs that part X fits" needs the reverse. You will run both. Composite indexes on (part_id, vehicle_config_id) should be a baseline.

For search, the practical approach is to denormalise fitment into your search index at index time. Each document in Elasticsearch carries the set of vehicle config IDs it fits. The search query filters on the user's vehicle config ID as a terms filter. At scale you'll want to measure whether a terms filter over 2,000 IDs per document is acceptable for your p99 latency. In most cases it is, until the catalogue grows past a few hundred thousand SKUs.

Catalogue Ingest and Refresh

ACES files come from suppliers in XML. You need an ingest pipeline that validates against the ACES XSD, diffs against your existing application records, applies updates, and flags conflicts (where two suppliers claim different fitment for the same part). This is not a one-time import. It's a scheduled job, ideally running weekly per supplier.

The diff step is where teams cut corners and pay later. Without it, every ingest is a full replacement. Full replacements are destructive to any manual fitment corrections your team has made. Diff-based ingest preserves manual overrides.

What Are the Real Trade-offs With Third-Party Fitment Data?

There are three primary data sources the industry uses.

Source	Coverage	Quality	Cost model
Auto Care Association VCdb/ACES direct	Canonical vehicle data	High	Annual licence fee
Catalogue aggregators (e.g. WHI Solutions/Epicor, DCi)	Broad brand coverage	Mixed, supplier-dependent	Per-transaction or SaaS
Supplier-direct ACES files	Brand-specific	Varies by brand maturity	Usually included with wholesale account

Aggregators are tempting because they offer a single integration point. The trade-off is that you inherit their data quality problems. A mapping error in their database becomes your customer's wrong fitment result. You typically have no fast path to correct it.

Supplier-direct files give you control and a clear escalation path when fitment is wrong. The trade-off is integration volume: 40 suppliers means 40 different file formats, delivery schedules, and communication contacts.

Most serious auto parts platforms end up running both: aggregators for breadth, supplier-direct files for the brands that matter most to their revenue mix.

Fitment Confidence and "Universal" Parts

Not every part has vehicle-specific fitment. Fluids, shop supplies, and universal parts (certain filters, some electrical components) either fit all vehicles or require a different kind of attribute-based matching. The ACES schema handles this with a "universal" flag on application records.

The UX question is how to handle these when a user has a vehicle selected. Showing them "universal fit" parts without context causes support tickets. Showing nothing causes missed sales. A reasonable approach is to display universal parts with an explicit label and a short explanation of what the user needs to verify before ordering.

Fitment confidence is a separate concept. Some application records come from manufacturer data. Some are derived from cross-reference. Some are community-reported. A confidence tier on the application record (manufacturer-verified, cross-reference, community) lets you surface that information to the buyer and also lets your operations team prioritise which mappings to audit.

Conclusion

If you're building an auto parts commerce platform and fitment is a line item under "product catalogue," stop and re-scope. It's a separate system with its own data model, ingest pipeline, search architecture, and UX surface area.

The concrete next step: before you write application code, model your application database schema against a real ACES sample file from your primary supplier. Import it into PostgreSQL. Run the queries a product page and a search results page would actually need. The performance and complexity you see there will tell you more than any architecture diagram.

FAQ

What is the difference between ACES and PIES data? ACES (Aftermarket Catalog Exchange Standard) defines which vehicles a part fits. PIES (Product Information Exchange Standard) defines the product attributes: dimensions, weight, images, pricing. You need both for a functional catalogue. They are separate XML schemas maintained by the Auto Care Association and are often delivered as separate files by suppliers.

How often does fitment data need to be updated? Supplier fitment files change frequently. A reasonable baseline is weekly ingestion per supplier. Major brands push updates whenever they add vehicle coverage or correct errors. Running ingest less frequently than monthly means you're actively serving stale fitment data, which leads to wrong-fit orders and returns.

Can we use a standard e-commerce platform like Shopify or Commercetools for auto parts? You can host the storefront on those platforms, but fitment data management cannot live in their native data models. You'll need a separate fitment service and a custom storefront integration. Shopify's metafields and Commercetools' custom attributes are not designed for hundreds of millions of application records.

What happens when fitment data from two suppliers conflicts? Conflicts are common. Supplier A says a part fits a 2018 Honda Civic 1.5T. Supplier B says it does not. The right approach is to flag conflicts during ingest rather than silently overwriting. A review queue lets your catalogue team resolve them, and the resolution gets recorded so it survives future ingests.

Is it worth building fitment tooling in-house or should we buy a solution? It depends on catalogue size and update frequency. If you have fewer than 10,000 SKUs and one or two suppliers, a simpler build is defensible. Above that, the complexity of multi-supplier ingest, conflict resolution, and search integration grows quickly. Several SaaS fitment platforms exist (Illumix, MyYear.io, and aggregators like Epicor) that handle the data layer, leaving you to build the application logic on top.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.