Last verified against Kaufland documentation: 23 August 2026
If you sell connected products through Kaufland Global Marketplace, the EU Data Act is no longer only a legal-policy issue. Kaufland has turned it into a product-data workflow.
For product categories Kaufland treats as relevant, sellers are asked to indicate whether the product is affected by the EU Data Act and, where it is, provide a manufacturer URL containing the relevant product information.
If you also sell through bol, the operational channel is different: bol's current public guidance focuses on document upload rather than Kaufland-style URL attributes. See the bol EU Data Act seller guide for that document-upload workflow.
In the Seller Portal, the two visible fields are:
- Concerns Data Act
- Smart Device Info URL
For CSV/XML workflows, Kaufland currently documents two corresponding product attributes:
is_smart_device— attribute ID 3872smart_device_manufacturer_information_url— attribute ID 3875
Kaufland also supports submission through its Marketplace Seller API.
The operational consequence is significant: Kaufland says the process must be completed for each individual relevant item, and it reserves the right to deactivate listings if relevant EU Data Act information is not submitted correctly.
This guide explains what Kaufland currently asks sellers to provide, where the underlying information should come from, how to handle the Seller Portal, CSV/XML and API workflows, what a Smart Device Info URL should actually point to, and how manufacturers and sellers can avoid maintaining the same Article 3 information manually across dozens or hundreds of SKUs.
Need the manufacturer source document first? Use the free EU Data Act Product Data Notice Generator to structure the underlying Article 3 product information before mapping it into marketplace fields.
Important: RegCatalog is independent and is not affiliated with or endorsed by Kaufland. Marketplace requirements can change. Always verify current Kaufland Seller University and Marketplace Seller API documentation before production submission.
Quick answer: what does Kaufland require for the EU Data Act?
Kaufland's current seller guidance says that, for relevant product categories, sellers must indicate whether a product falls under the EU Data Act requirements.
If it does, the seller must provide a link containing information about the data collected, processed and stored by the device.
Kaufland tells sellers that this information can normally be requested from the manufacturer, which typically provides a URL to a page with the relevant information.
The seller then associates that URL with the product.
Current Kaufland submission methods are:
- manual Seller Portal entry
- CSV/XML product-data import
- Marketplace Seller API
Official source:
Kaufland Global Marketplace — EU Data Act Seller University
The two Kaufland Data Act fields sellers need to understand
Kaufland has made the workflow unusually concrete.
1. Concerns Data Act
In the Seller Portal, Kaufland asks whether the product is affected.
The seller selects:
- Yes
- No
Kaufland's CSV/XML equivalent is:
is_smart_device
Current attribute ID:
3872
Kaufland's public guidance says the field should be populated with Yes or No.
2. Smart Device Info URL
If the answer is Yes, Kaufland asks for the manufacturer's URL containing the relevant information.
Seller Portal label:
Smart Device Info URL
CSV/XML field:
smart_device_manufacturer_information_url
Current attribute ID:
3875
The key word here is manufacturer.
Kaufland's guidance does not suggest that sellers should invent the product-data information themselves when they do not control the technical product facts. It tells sellers they can request the information from manufacturers of affected products and will typically receive a URL.
That is a much safer product-information workflow:
manufacturer creates canonical information → seller references it
rather than:
every reseller writes its own interpretation of the device's data behavior.
Why these fields exist: the Article 3 connection
Kaufland links its guidance directly to Article 3 of Regulation (EU) 2023/2854.
Article 3(2) requires specified information to be provided before a contract for purchase, rent or lease of a connected product is concluded.
For covered connected products, Article 3(2) includes information about:
- the type, format and estimated volume of product data the product can generate;
- whether the product can generate data continuously and in real time;
- whether it can store data on-device or on a remote server, including intended retention where applicable;
- how the user may access, retrieve or, where relevant, erase the data, including technical means, terms of use and quality of service.
Primary legal source:
Regulation (EU) 2023/2854 — Data Act
For a detailed explanation of those fields, see:
EU Data Act Product Data Notice Guide
This distinction matters because Kaufland only needs a marketplace field and URL, but the URL must lead somewhere useful.
A blank landing page, homepage link, generic privacy policy or corporate Data Act statement may not contain the product-specific information the customer needs.
What should the Smart Device Info URL point to?
Kaufland says sellers should add the manufacturer's URL containing the relevant information.
A good Smart Device Info URL should therefore lead directly to the relevant product or product-family information.
Strong URL pattern
https://manufacturer.com/eu-data-act/smart-camera-x100or:
https://manufacturer.com/legal/data-act/product-family-xWeak URL pattern
https://manufacturer.com/or:
https://manufacturer.com/privacyor a generic page saying only:
We comply with the EU Data Act.
The user should not have to search the manufacturer's entire site to discover which data a specific product generates.
What the linked page should ideally contain
For the product or clearly identified product family:
- manufacturer identity;
- product/model/family;
- notice version or last-updated date;
- generated product-data categories;
- formats;
- estimated data volumes or meaningful estimates;
- continuous / real-time generation status;
- storage method;
- retention where applicable;
- user access/retrieval method;
- erasure where relevant;
- technical means;
- terms of use;
- quality-of-service information where applicable;
- relevant contact or data-access link.
The exact legal requirements depend on the product and roles involved, but this structure maps well to Article 3(2).
Stable URLs are better than disposable documents
For Kaufland specifically, a stable manufacturer URL is operationally valuable.
Why?
Because the same URL may be associated with:
- one SKU;
- a product family;
- several seller accounts;
- several Kaufland storefronts;
- other marketplaces or distributors.
If the technical information changes, a manufacturer can update the canonical page rather than emailing a new PDF to every reseller.
This is also consistent with Recital 24 of the Data Act, which contemplates making pre-contractual information available through a stable URL that can be distributed as a web link or QR code.
For manufacturers, the ideal architecture is:
Product data source
↓
Canonical Product Data Notice URL
↓
Kaufland seller product fieldnot:
Engineer spreadsheet
↓
Legal Word file
↓
Seller PDF
↓
Old marketplace attachment
↓
Different reseller versionMethod 1: enter Kaufland Data Act information manually
Kaufland's Seller University currently documents this process:
- Open the relevant offer/product data.
- Go to the product's Attributes.
- Find Concerns Data Act.
- Select Yes or No.
- If Yes, add the manufacturer's URL under Smart Device Info URL.
- Repeat for each relevant item.
This is appropriate when:
- you have a small catalogue;
- only a few products are affected;
- you do not operate a feed or marketplace integration.
Manual workflow checklist
For each product:
- Verify the relevant product/category.
- Determine the Data Act status using your legal/product-compliance process.
- Obtain the manufacturer's current information URL.
- Confirm the URL resolves publicly.
- Confirm it actually identifies the product or product family.
- Set Concerns Data Act.
- Enter Smart Device Info URL if applicable.
- Recheck the listing after product-data processing.
What not to do
Do not choose Yes/No based only on:
- whether the product has Wi-Fi;
- whether the category name contains “smart”;
- whether another seller selected Yes;
- whether a chatbot says the product is connected.
For the legal concept, start with the Article 2(5) connected-product definition.
See:
What Is a Connected Product Under the EU Data Act?
Method 2: use CSV or XML for Kaufland Data Act fields
For sellers managing more than a handful of SKUs, CSV/XML is usually more scalable.
Kaufland's current documentation identifies:
| Kaufland field | ID | Purpose |
|---|---|---|
is_smart_device | 3872 | Yes/No Data Act status |
smart_device_manufacturer_information_url | 3875 | Manufacturer URL |
Kaufland says both attributes can be populated simultaneously.
Conceptual example
A product-data record might conceptually contain:
ean: 1234567890123
manufacturer: Example Devices GmbH
is_smart_device: Yes
smart_device_manufacturer_information_url:
https://example.com/eu-data-act/sensor-x100This is illustrative, not a complete Kaufland product-data feed.
Your actual CSV/XML format must follow Kaufland's current Product Data file specification.
Why attribute IDs matter
Kaufland's product-data model is attribute-driven.
Its Marketplace Seller API documentation explains that:
- products belong to categories;
- categories expose required, optional and conditional attributes;
- attributes have stable internal IDs and English names;
- current category-specific attributes can be retrieved through API endpoints.
This means a robust in-house integration should not treat a copied spreadsheet from 2025 as a permanent API contract.
Use Kaufland's current category/attribute metadata to validate your production implementation.
Official API documentation:
Kaufland Marketplace Seller API — Managing Product Data
Method 3: submit via the Kaufland Marketplace Seller API
Kaufland also explicitly supports API submission.
The public Seller University page directs developers to the Marketplace Seller API documentation.
The API documentation explains Kaufland's product-data architecture:
- product data are separate from seller inventory/offer data;
- a product can have multiple seller offers attached;
- products belong to a category;
- category-specific attributes can be queried;
- product data can be submitted through Kaufland's product-data interfaces.
Why this matters for larger sellers and PIM teams
If you already use:
- a PIM;
- ERP;
- marketplace feed manager;
- custom middleware;
- an ecommerce integration platform;
the EU Data Act fields should be treated as product attributes, not a manual afterthought.
A sensible internal architecture is:
Manufacturer source URL
↓
PIM / product master
↓
Data Act status
↓
Kaufland feed adapter
↓
Kaufland product attributesThat prevents an ecommerce employee from manually researching the same manufacturer URL every time the product catalogue is refreshed.
Do not hard-code more than you have verified
As of 23 August 2026, the two fields above are documented by Kaufland.
But marketplace schemas change.
A production integration should:
- keep field names and IDs in one adapter/config module;
- store the official source URL;
- store a last-verified date;
- recheck Kaufland documentation periodically;
- surface failed/missing attribute submissions.
That is safer than scattering 3872 and 3875 across scripts and spreadsheets.
Which Kaufland marketplaces does this matter for?
Kaufland Global Marketplace currently markets one seller registration across nine marketplaces and says sellers can reach up to 220 million potential online customers across its marketplace network.
Its current marketplace list includes:
- Germany
- Czech Republic
- Slovakia
- Poland
- Austria
- France
- Italy
- Spain
- Netherlands
See:
Kaufland Global Marketplace seller registration
For Data Act purposes, do not assume a product-data record should be maintained independently nine times if Kaufland can reuse the same canonical manufacturer information.
The stronger approach is to maintain one accurate manufacturer source and then map it into each required storefront/feed context.
Kaufland categories affected by the EU Data Act
Kaufland publishes a downloadable list of categories it currently treats as affected.
Its Seller University links to a file titled:
Final List Leaf Categories - EU Data Act.xlsx
Kaufland also explicitly invites sellers to suggest additional categories through Seller Support and says it may expand the list.
This tells us two things.
1. The category list is operational guidance, not a permanent legal taxonomy
Kaufland can change or expand it.
2. A product can still require legal review
Kaufland itself includes a disclaimer saying its seller guidance does not replace legal advice and sellers should determine whether their products fall within the relevant requirements.
So do not build an internal rule saying:
not on current Kaufland spreadsheet = legally outside Data ActThe marketplace category list is an important operational signal, not the full legal test.
Official category-list link is available from:
Kaufland Seller University — EU Data Act
Kaufland can deactivate listings when information is wrong or missing
This is one of the most commercially important parts of the Kaufland guidance.
Kaufland states:
If relevant EU Data Act information is not submitted correctly, the marketplace reserves the right to deactivate listings.
That means the workflow has a direct ecommerce consequence.
For sellers, the risk is not only:
compliance team asks for another document.
It can become:
product listing is no longer active.
For manufacturers that rely on reseller networks, that creates a second-order problem:
If your distributors cannot obtain a clean manufacturer URL, their listings can become harder to maintain.
This is why manufacturers should treat Article 3 product information as channel-ready product data.
Manufacturer vs. reseller responsibilities in practice
Kaufland's guidance creates a clear operational dependency between manufacturer and seller.
Manufacturer's practical job
The manufacturer should be able to supply:
- clear product identification;
- current Product Data Notice/information;
- stable public URL;
- enough specificity to identify the covered SKU/family;
- update ownership.
Seller's practical job
The Kaufland seller should:
- determine/confirm marketplace product status through its compliance process;
- associate the correct manufacturer URL;
- maintain the Kaufland attribute;
- ensure the URL remains valid;
- update product data if the manufacturer changes its source URL.
Why resellers should not write technical facts they cannot verify
A reseller may not know:
- whether a device stores data remotely;
- the intended retention period;
- data format;
- estimated volume;
- whether generation is continuous;
- how a manufacturer backend exposes the data.
Those are manufacturer/product-engineering facts.
Where possible, use the manufacturer's official information rather than creating an unsupported reseller-authored description.
What if the manufacturer has no Data Act page?
This is a common operational failure case.
You have a Kaufland product that needs a manufacturer information URL, but the manufacturer website has:
- no Product Data Notice;
- no obvious Data Act page;
- only a privacy policy;
- only a general contact page.
Seller workflow
- Contact the manufacturer.
- Request the product-specific EU Data Act information.
- Ask for a stable public URL.
- Confirm which models/SKUs the information covers.
- Confirm when it was last updated.
- Avoid inventing technical details if you do not control the product.
Manufacturer workflow
If you are the manufacturer receiving these requests:
- identify the connected product/product family;
- map generated product data;
- document Article 3 information;
- publish a stable URL;
- give that URL to distributors/sellers.
RegCatalog's generator is designed around this source-document step:
Generate a Product Data Notice
Can the manufacturer use one URL for many SKUs?
Potentially, yes — if the page clearly covers those SKUs and the data characteristics are actually the same or differences are clearly documented.
For example:
Product family: Smart Sensor X Series
Covered models:
- X100
- X110
- X120If all three models generate the same categories, formats and access behavior, one family notice may be operationally sensible.
If X120 adds:
- GPS/location data;
- a new cloud service;
- different retention;
then the family page should document that variation clearly or use a separate notice.
The objective is not to maximize URL reuse.
The objective is to make the product information accurate and unambiguous.
What should manufacturers put in the canonical page?
A practical manufacturer page can use this structure.
Notice identity
- Product Data Notice
- manufacturer
- product/product family
- model/SKU coverage
- version
- last updated
Product data generated
For each category:
- type/nature;
- format;
- estimated volume;
- generation frequency;
- continuous?
- real-time?
Storage
- on-device?
- remote server?
- transient?
- retention?
Access and retrieval
- app?
- web portal?
- API?
- direct-device interface?
- request process?
Erasure
- available?
- how?
- limitations?
Technical means, terms and quality of service
- access mechanism;
- terms link;
- service conditions where applicable.
Contact
- manufacturer/data-holder contact;
- support or data-access route.
For a full field-level explanation:
EU Data Act Product Data Notice Guide
A practical Kaufland workflow for manufacturers
If you manufacture connected products that are resold through Kaufland sellers, use this workflow.
Step 1 — Identify product coverage
For each family:
- EAN/GTIN;
- SKU;
- model;
- applicable notice.
Step 2 — Create the source notice
Collect technical facts from:
- engineering;
- firmware;
- cloud/backend;
- product management;
- compliance.
Step 3 — Publish a stable URL
Prefer:
manufacturer.com/eu-data-act/product-xAvoid changing the path unnecessarily.
Step 4 — Create a reseller handoff table
Example:
| SKU | GTIN | Product | Data Act URL |
| X100-BLK | ... | Sensor X100 Black | https://.../sensor-x |
| X100-WHT | ... | Sensor X100 White | https://.../sensor-x |
| X120 | ... | Sensor X120 | https://.../sensor-x120 |
Step 5 — Send it to distributors
Do not make every reseller search the legal section of your website.
Step 6 — Review after product changes
Trigger review when:
- firmware changes data generation;
- a cloud service is added;
- data format changes;
- retention changes;
- user access changes;
- product family changes.
A practical Kaufland workflow for marketplace sellers
If you are a reseller:
Step 1 — identify candidate products
Use Kaufland's current affected-category guidance plus your own compliance process.
Step 2 — locate manufacturer source information
Look for:
- Data Act
- Product Data Notice
- Data Notice
- pre-contractual information
- connected product information
Step 3 — verify product coverage
Make sure the URL identifies:
- the exact model;
- or a family that clearly includes it.
Step 4 — set Kaufland attributes
Manual, feed or API.
Step 5 — monitor failures
Check:
- invalid URL;
- 404;
- wrong product;
- missing field;
- category/attribute changes.
Step 6 — retain the manufacturer source
Keep a simple internal record:
EAN
Manufacturer
Product
Kaufland status
Manufacturer URL
Last checked
OwnerThis is particularly valuable for multi-brand sellers.
Common Kaufland EU Data Act mistakes
Mistake 1: putting the manufacturer's homepage in Smart Device Info URL
A homepage is usually not specific enough.
Use the direct product-data page where possible.
Mistake 2: using the privacy policy
A GDPR privacy policy and an Article 3 Product Data Notice answer different questions.
Mistake 3: marking every Wi-Fi product Yes without scope review
Kaufland uses seller-facing marketplace terminology, but the legal connected-product definition is more precise.
Mistake 4: assuming “No” because the product is not cloud-connected
The Data Act connected-product definition also recognizes physical connection and on-device access.
Mistake 5: copying another seller's URL
Confirm the manufacturer source yourself.
Mistake 6: maintaining a separate manually written notice per reseller
Manufacturers should prefer one canonical source where possible.
Mistake 7: putting field IDs in multiple spreadsheets/scripts
Centralize:
is_smart_devicesmart_device_manufacturer_information_url
in a maintained feed adapter/configuration.
Mistake 8: ignoring the official category list
Kaufland publishes marketplace-specific affected-category guidance.
Use it operationally.
Mistake 9: treating the category list as the law
The legal classification is still based on the Data Act.
Mistake 10: assuming submitted data can never change
Kaufland can update its marketplace schemas and category treatment.
Re-verify.
How the Kaufland API architecture affects implementation
Kaufland's API documentation is useful for understanding why RegCatalog treats marketplace mapping as a product-data problem.
The Marketplace Seller API separates:
- product data
- inventory/offer data
Multiple sellers can offer the same product while Kaufland maintains a product-data representation assembled from different sources.
Kaufland also exposes category and attribute metadata through API endpoints.
For developers, useful patterns include:
- category lookup;
- category-specific attributes;
- attributes by name or ID;
- product lookup;
- product-data upload.
See:
Kaufland Marketplace Seller API — Managing Product Data
Engineering recommendation
If you maintain an in-house integration:
internal product schema
↓
Kaufland adapter
↓
resolve category attributes
↓
build product payload/feed
↓
submit
↓
check processing resultDo not bury marketplace-specific field names inside generic product models.
That makes later schema changes easier to maintain.
How RegCatalog should map Kaufland fields
RegCatalog's long-term Kaufland adapter should remain simple.
Source facts
RegCatalog product record:
- seller/manufacturer's scope confirmation;
- canonical Product Data Notice URL.
Kaufland output
Kaufland EU Data Act mapping
is_smart_device
Yes
smart_device_manufacturer_information_url
https://manufacturer.com/eu-data-act/product-xThen:
- Copy values
- Download CSV
- Show source link
- Show last-verified date
RegCatalog should not determine is_smart_device = Yes automatically from product marketing text.
That status should be confirmed by the user/company responsible for the marketplace submission.
Why this search intent matters for manufacturers, not only Kaufland sellers
A manufacturer may not operate a Kaufland seller account.
But its resellers do.
That means “Kaufland EU Data Act” is still a manufacturer product-data problem.
If five resellers ask:
What URL should we put in Smart Device Info URL?
the manufacturer needs one answer.
The same principle can extend to other sales channels.
This is the underlying RegCatalog thesis:
Maintain the product regulatory facts once and publish them into the formats each channel asks for.
Kaufland is a particularly clear example because the marketplace has already defined explicit product attributes.
Kaufland EU Data Act checklist
Product scope
- Confirm product identity / EAN / SKU.
- Review Kaufland's affected-category guidance.
- Review connected-product scope.
- Check whether Article 7 enterprise-size rules are relevant.
- Record the person/team responsible for the Yes/No decision.
Manufacturer source
- Direct manufacturer source found.
- URL is publicly accessible.
- URL uses HTTPS.
- Page identifies product/product family.
- Page contains product-data information.
- Last-updated/version information checked.
- URL is stable enough for marketplace use.
Kaufland Seller Portal
- Concerns Data Act selected.
- Smart Device Info URL populated if Yes.
- Product-specific entry checked.
CSV/XML
is_smart_devicepopulated.- Attribute ID 3872 re-verified.
smart_device_manufacturer_information_urlpopulated where applicable.- Attribute ID 3875 re-verified.
- Feed processed successfully.
API
- Current Kaufland API docs checked.
- Category-specific attribute metadata validated.
- Current storefront/locale handling checked.
- Submission response monitored.
Ongoing maintenance
- Manufacturer URL monitored.
- 404/redirect changes checked.
- Kaufland requirements reviewed periodically.
- Product changes trigger notice review.
- New SKUs inherit the correct source URL only when technically accurate.
Frequently asked questions
What is the Kaufland EU Data Act requirement?
Kaufland currently requires sellers in relevant product categories to indicate whether the product is affected by the EU Data Act and, where it is, provide a manufacturer URL with the relevant information.
What is the Kaufland Smart Device Info URL?
It is the Seller Portal field used to provide the manufacturer's URL containing the relevant EU Data Act product information.
What is is_smart_device on Kaufland?
It is the current Kaufland CSV/XML product attribute used to indicate Yes/No for whether the product is affected by the Data Act workflow. Kaufland currently documents attribute ID 3872.
What is smart_device_manufacturer_information_url?
It is the current Kaufland CSV/XML field for the manufacturer URL containing the relevant information. Kaufland currently documents attribute ID 3875.
Can I submit Kaufland Data Act information manually?
Yes. Kaufland documents manual Seller Portal entry under the product's Attributes section.
Can I upload Kaufland Data Act fields by CSV or XML?
Yes. Kaufland explicitly documents CSV/XML submission for the two Data Act attributes.
Can I submit the fields through the Kaufland Seller API?
Yes. Kaufland's Seller University points sellers to its Marketplace Seller API documentation for API submission.
Does the Smart Device Info URL need to be the manufacturer's homepage?
No. Kaufland asks for the manufacturer's URL containing the relevant information. A direct product/product-family Data Act page is more useful than a generic homepage.
Can I use a PDF URL?
Kaufland's guidance refers to a URL from the manufacturer. If a stable public PDF URL contains the relevant product information it may function as a URL resource, but a stable HTML product page can be easier to update. Verify Kaufland's current acceptance and your own implementation requirements.
Does Kaufland require the process for every product?
Kaufland's current guidance says the manual process must be repeated for each individual item. Feed/API methods make this scalable for larger catalogues.
Can Kaufland deactivate listings over missing Data Act information?
Kaufland states that if relevant EU Data Act information is not submitted correctly, it reserves the right to deactivate listings.
How do I know whether my product is affected?
Use Kaufland's current category guidance operationally, but the legal connected-product analysis should be based on Regulation (EU) 2023/2854. Kaufland itself tells sellers to seek legal advice where necessary.
Is every smart device automatically subject to the Data Act?
No. “Smart device” is Kaufland's operational marketplace terminology. The legal test is based on the connected-product definition and other Data Act scope rules.
Are small sellers exempt?
The seller's size alone does not determine the product's Article 7 status. Article 7 focuses on the qualifying manufacturer/designer/related-service provider behind the product data.
What if the manufacturer has no Product Data Notice?
Contact the manufacturer and request the required product information and a stable URL. Avoid inventing technical product facts you cannot verify.
Can one manufacturer URL cover several variants?
Potentially, if the page clearly identifies all covered models and accurately describes any differences. Do not reuse a family URL where product-data behavior materially differs.
Does RegCatalog submit directly to Kaufland?
Not unless a real integration has explicitly been implemented and documented. RegCatalog's initial purpose is to help structure the manufacturer source record and prepare marketplace-ready values.
Should I hard-code attribute IDs 3872 and 3875 forever?
No. They are current documented Kaufland values as of 23 August 2026. Marketplace schemas can change. Keep them in a maintained adapter and periodically verify the official documentation.
What should a Product Data Notice contain?
For Article 3(2), the core information includes product-data type, format, estimated volume, continuous/real-time generation, storage/retention and user access/retrieval/erasure information including technical means, terms and quality of service.
Build the manufacturer source record once
Kaufland demonstrates a broader shift in connected-product ecommerce.
The marketplace does not need your internal legal memo.
It needs an answer at the product-data level:
Does the product concern the Data Act?
↓
Where is the manufacturer's product information?For sellers with 10 products, this can be managed manually.
For manufacturers or sellers with 100, 1,000 or 100,000 products, the scalable model is different:
Manufacturer product catalogue
↓
Canonical Article 3 source record
↓
Stable manufacturer URL
↓
Kaufland mapping
↓
Seller Portal / CSV / XML / APIThat is the workflow RegCatalog is being built to support.
Useful next steps
- Generate a Product Data Notice
- Read the Article 3 Product Data Notice guide
- Check what counts as a connected product
- Understand the Article 7 SME exemption
Primary sources and further reading
Kaufland
- Kaufland Global Marketplace — EU Data Act
- Kaufland Marketplace Seller API — Managing Product Data
- Kaufland Seller University
- Kaufland Global Marketplace seller registration / marketplace network
EU Data Act
- Regulation (EU) 2023/2854 — Data Act
- European Commission — Data Act explained
- European Commission — Data Act
_RegCatalog is an independent informational product-data tool. It is not affiliated with, sponsored by or endorsed by Kaufland. RegCatalog does not provide legal advice or certification. Kaufland product fields, category coverage, API behavior and enforcement processes can change; verify current Kaufland documentation before submitting production product data._