Kaufland product feed integration: what the data model demands

Kaufland does not accept a single file of products and prices. It accepts product data that feeds a shared catalogue record, and separately an offer: your price, stock, handling time and your own identifier. Most integration trouble starts with squeezing both into one “feed”, in the sense that a Google Shopping file is a feed.

This article describes the Kaufland data model from the implementation side: what the key is, which fields are required, what happens to data after submission, and where these builds break most often. All of it checked in the Seller API documentation on 27 October 2026. If you are after tooling rather than the model, we have a separate piece on building feeds with an agent.

Two things go to Kaufland, not one

The documentation puts this split on page one: product data and inventory data are kept separate. A product is a catalogue entry shared by every seller. An offer, called a unit in the docs, is inventory data for a single product from a single seller. One product record, many units attached to it.

The consequence is practical. A price or stock change never touches the catalogue, and a fix to the title never changes your offer. Two different operations, two schedules, two places where something can stall.

Your offer is identified by your own id_offer, which must be unique across your entire inventory. Kaufland keeps warehouse and quantity in sync by that identifier, so it, rather than the EAN, is the key on your side of the integration. Creating a unit also requires a listing price above zero, a condition, and a handling time counted in working days.

EAN decides whether the product exists at all

The product data file documentation is blunt about this: every product has an EAN, and without the EAN Kaufland cannot identify the product. The EAN is the glue between your offer, the catalogue record, and the offers other sellers hold against the same product.

For an own brand that means work to plan before the integration: obtaining and assigning codes to every variant you intend to sell separately. Mapping by SKU does not replace it. Bundles, multipacks and size variants are separate products, so they need separate codes.

Missing EANs are the single most common reason a Kaufland integration stalls halfway for a fortnight.

File format: semicolons, UTF-8, a locale on every row

If the data goes as a file rather than through the API, the requirements are specific and worth knowing before the first export. Below is what the documentation states directly.

That last row is a trap. Automatic categorisation works while the catalogue is conventional, and on products that sit between categories it starts placing items in branches that carry different required attributes and different filters. For the assortment that matters to revenue, state the category explicitly.

Your data is a candidate for the description

This is the part of the model that surprises people most. A Kaufland product description is assembled from several sources: product information services, sellers, manufacturers, and Kaufland own product data team. The documentation says plainly that some of the data you upload may not be selected for the final description.

For anyone arriving from Amazon or from their own store, that is a change of habit: the product page is shared, not yours.

The implication for implementation: do not build a process whose success metric is “our copy is on the page”. The metric is the state of your offer and its visibility. Send well-prepared content, because it raises the chance of being selected, but what you control is the offer.

What happens after you submit

Data does not go live when the response arrives. The update status starts as pending and moves to in progress while automatic or manual checks run. Some values, the docs note, go to manual review by the category management team. At the end the offer is either visible or blocked with one of the reason codes.

There are twenty-four reason codes and they cover things no export can fix on its own: missing brand authorisation, doubts about authenticity, missing certification, regulatory restrictions, product safety. Which means the integration has to read them and put them in front of a person, because the fix lives in documents or in a business decision rather than in the file.

Where these integrations break in practice

Across our channel builds the same four problems come back, always in the same order.

• One-way push. Data leaves for the channel and nobody reads statuses or block codes. The seller portal becomes the only place where the truth lives, so nobody checks it regularly.
• Mapping in a spreadsheet. Attribute and category assignment lives in a file on one person laptop. When channel requirements change there is nothing to version and nothing to test.
• Offers updated per product. Stock and price pushed by EAN instead of by id_offer drift apart as soon as the same product exists in two warehouses or two conditions.
• One locale treated as a translated title. Markets differ in required attributes and filter expectations too, and the row-level locale is where those differences have to be handled.

How to build it so it survives

The architecture that holds up over time has four layers, each responsible for one thing.

• The catalogue as the source of truth. One place holding product data, feeding every channel. Without it each channel starts living its own life.
• A mapping layer per channel. The Kaufland schema described in code: required attributes, categories, units, locales. A change in channel requirements becomes one file and one test.
• Validation before sending. A missing EAN, a zero price, a negative handling time or a duplicate id_offer surface on your side rather than in moderation. Cheap, and immediate.
• A queue with retries and state reads. Every submission carries an identifier, and its state is polled and stored. Blocks land on a human list with the code and the product.

That is exactly the scope we deliver as feed automation, and as channel expansion when a new channel goes live. If your catalogue sits in a store and you want it on Kaufland without hand-editing files, write to us and let us look at your product data together.

One caveat to close with. Kaufland changes its requirements independently of us, and figures the documentation does not state, such as file size limits or time to publication, deliberately do not appear here. Check the current Seller API documentation before you build.