Working together: two decades · Core PIM programme: 2019 - 2021, still developed and maintained today · Client figures: 2020 · Industry: automotive aftermarket distribution · Delivered by i4B
i4B and LKQ Europe have been working together for two decades. LKQ Europe is a distributor supplying around 100,000 independent companies in more than 20 European countries. In Q4 2019 that long relationship turned into a dedicated product-data programme: between 2019 and 2021 we built four core services - a DataMatrix API carrying product range and trading rules, a Vehicle Core Service unifying vehicle identification across countries, a Product Core Service that onboards catalogues over plain CSV, and an Order Management Core Service that connects more than 300 B2B customers in Central and Eastern Europe to 15 different ERP and ordering systems through gRPC plugins. We have been developing and maintaining them ever since.
Collaboration context
LKQ is a leading distributor of automotive aftermarket parts, and our two companies have worked together for some twenty years. The product-data programme described here started in Q4 2019, at the time of LKQ's expansion into the markets of Central and Eastern Europe. Its four build stages ran to 2021, each alongside a Product Owner on the client's side - and the work has not stopped: in 2026 we are still developing and maintaining these services, and still working with the wider organisation.
This project sits in our auto parts and electrical wholesale practice, alongside our work on TecDoc integration and catalogue data quality.
Client information
LKQ Europe GmbH, a subsidiary of LKQ Corporation. Figures for 2020.
Four stages, four core services
Stage 1 · DataMatrix API and demo app
Build a web API that lets the company manage its product range across Europe. The trading rules are involved: who may and may not trade particular parts, how brands are sorted and promoted, and which assortment to display depending on a car's brand and its mileage.
A rules engine built on norms we designed for classifying products and services, plus a tested web API with instant synchronisation of the data a user needs. And a simple front-end application - we still use it today to demonstrate what the API can do to non-technical audiences.
Stage 2 · Vehicle Core Service
We started with a single EMDM catalogue, but the number of systems interpreting vehicle data kept growing - usually one per country, per way of searching. Each country may have a different supplier for VIN and VRM numbers, and another one for the car's general specification.
Unified requests and responses, plus a configuration that lets business people set which supplier handles which country and which type of search - with no developer involved.
Stage 3.1 · Product Core Service
Not every company keeps product data in standard systems such as EMDM or TecDoc. Many smaller suppliers maintain catalogues of their own - in bespoke software, or in plain Excel tables.
Import through a simple CSV file whose headers indicate product groups. Any database can generate a CSV, so the barrier to entry is zero. Once processed, the data lands in our structure and is served through the product API.
Stage 3.2 · Infrastructure as code
After a security audit the IP addresses had to change. Without infrastructure as code that would have meant editing them by hand in every layer of the application.
The entire infrastructure lives in the repository. Changing the code in a few places propagated across the environment automatically, and any change with a negative impact can be redeployed away. The shared repository also keeps test versions in order. Our DevOps team has owned this environment ever since.
Stage 4 · Order Management Core Service
Serve ERP product data across Europe with no single main data source - instead, distributed solutions on different technologies: file exchange over SFTP, SOAP, JSON-RPC, REST API, even email. Every client team works in something different.
A contract on gRPC, chosen so that application loading speed would be a benchmark for others. Supporting gRPC is the only requirement for a plugin author, so the work split across teams and languages - our team writes in C#, the external team in Go. Plugins deploy independently of one another. The plugin set keeps growing; today we support 15 different ordering systems.
Inside the ordering layer
Technologies
Outcome
Two decades of working together, and i4B remains LKQ Europe's technology partner - over 300 customers in the CEE region check prices and place orders through modules we keep running in production.
The build stages ran from 2019 to 2021, but this is not a project that was handed over and closed. The application is in continuous development under an agile process, and the working setup - our team plus a Product Owner on LKQ's side, with skills adjusted to each stage - has held since 2019. Day by day, we are adding more solutions and integrating more customers.
Key terms
- DataMatrix
- The web API we built in Stage 1. It carries LKQ's product range together with the trading rules that decide which parts a given buyer may see and in what order.
- EMDM catalogue
- The master-data catalogue the Vehicle Core Service started from, before per-country vehicle identification systems were added alongside it.
- TecDoc
- The automotive aftermarket catalogue standard maintained by TecAlliance. Larger parts suppliers publish their data there; smaller ones often do not, which is why CSV import exists.
- VIN / VRM
- Vehicle Identification Number and Vehicle Registration Mark - the two identifiers used to look a car up. Each European country may source them from a different supplier.
- gRPC
- The remote-procedure-call framework behind the Stage 4 plugin contract. It was chosen for loading speed and because it lets plugins be written in different languages.
Frequently asked questions
What exactly did i4B build for LKQ Europe?
Four core services, built in stages between Q4 2019 and 2021: the DataMatrix API with a rules engine for product range and trading permissions, the Vehicle Core Service for vehicle identification across countries, the Product Core Service for catalogue import, and the Order Management Core Service for ERP and ordering integrations. A DevOps team has owned the infrastructure as code since 2020, and all four services are still developed and maintained today.
How does one ordering API connect to 15 different ERP systems?
Through plugins behind a single gRPC contract. Each plugin wraps one ordering system, whatever protocol that system speaks - SFTP file exchange, SOAP, JSON-RPC, REST or email. Supporting gRPC is the only requirement on a plugin author, so plugins can be written in different languages by different teams and deployed independently of one another.
Can a parts supplier be onboarded without TecDoc or EMDM data?
Yes. The Product Core Service accepts a plain CSV file whose column headers indicate product groups. Any database or spreadsheet can produce one, so suppliers keeping their catalogue in bespoke software or in Excel can be onboarded without first joining a standard catalogue. Once processed, their data is served through the same product API as everything else.
Who decides which vehicle-data supplier is used in a given country?
Business users, not developers. The Vehicle Core Service exposes a configuration where the supplier is set per country and per type of search, so adding a market or switching a data provider does not require a release.
