Zuletzt aktualisiert:

Kaufland-Kassenbons automatisch importieren — Machbarkeits-Recherche

Tiefenrecherche · 07.06.2026 · für Dennis (Silverscale Family Hub) · zweiter Bon-Import-Weg analog zur Lidl-Plus-Anbindung

Frage: Können wir Kaufland-Kassenbons automatisch in die Familien-App ziehen (Bon-Archiv, Preisstatistik, Vorrat) — so, wie heute schon lidl.py + importer.py die Lidl-Plus-Bons holen?

1. Executive Summary — Verdikt

Machbar, aber nicht 1:1 wie bei Lidl. Es gibt die Datenquelle (Kaufland Card führt seit Mitte 2024 digitale Kassenbons in der App, 3 Jahre gespeichert, als PDF exportierbar), und Kaufland sitzt unter derselben Mutter (Schwarz-Gruppe) und derselben Auth-Technik (NetIQ Access Manager / NIDP) wie Lidl. Aber:

Empfehlung (gestuft, vom kleinsten Risiko aufwärts):

  1. Sofort & risikofrei: PDF-Bon-Import. Kaufland-Bons lassen sich in der App als PDF speichern/teilen. Wir haben bereits eine KI-Job-Queue mit Bildverarbeitung (ADR-13, ai_jobs.py, Sonnet mit Bild-Input). Ein neuer Job-Typ „Bon-PDF → strukturierte Positionen" füttert direkt unsere receipts/receipt_items-Tabellen mit store='Kaufland'. Manueller Trigger (Dennis exportiert nach einem Einkauf 1 PDF), kein ToS-Bruch, sofort nutzbar.
  2. Mittelfristig & wenn es sich lohnt: App-API reverse-engineeren → kaufland.py analog lidl.py, dann automatischer Cron-Pull wie bei Lidl. Höherer Aufwand, kleines ToS-/Sperr-Risiko, eigenständige Recherche-Session am echten Traffic nötig.

Für „erstmal Kaufland-Bons drin haben" ist Weg 1 die richtige Wahl. Weg 2 ist die Komfort-Kür, falls Kaufland zu einem regelmäßigen Einkaufsort wird.

2. In einfachen Worten

Bei Lidl haben wir einen kleinen Roboter (lidl.py), der sich mit deinem Lidl-Plus-Login bei Lidls Server meldet und jede Nacht die neuen Kassenbons abholt — fix und fertig als saubere Datenliste. Das geht so gut, weil jemand anderes vor uns herausgefunden hat, wo genau Lidls App ihre Bons abruft, und das als Bauanleitung ins Netz gestellt hat.

Für Kaufland gibt es diese Bauanleitung nicht. Kaufland hat zwar seit 2024 auch digitale Bons in seiner App (und gehört sogar derselben Firma wie Lidl), aber niemand hat öffentlich aufgeschrieben, wie man da rankommt. Wir müssten das selbst herausfinden — mit einem „Mithörgerät" zwischen Handy und Kaufland-Server. Machbar, aber Bastelarbeit, und Kaufland könnte das theoretisch unterbinden.

Der bequeme Sofort-Weg: In der Kaufland-App kannst du jeden Bon als PDF speichern. Unsere App kann schon heute Bilder/Dokumente mit KI lesen (das machen wir beim Foto-Bon und beim Barcode-Scan). Also: nach dem Einkauf einmal das Bon-PDF in die App geben, die KI liest Artikel, Preise, Pfand, Steuersätze heraus und legt es genauso ab wie einen Lidl-Bon — nur mit dem Stempel „Kaufland". Kein Hacken, kein Risiko, sofort fertig.

3. Recherche-Ergebnisse je Punkt

3.1 Kaufland-Ökosystem: Gibt es digitale Bons? (Ja)

Bedeutung für uns: Die Datenquelle existiert, ist persönlich (deine eigenen Einkäufe), enthält Positionen, und ist als PDF rausholbar — das ist die verlässliche Konstante, egal ob die App-API knackbar ist.

Quellen: Kaufland-Presse Juli 2024 · Lebensmittelpraxis · Lebensmittelzeitung: digitalen Kassenzettel aufgewertet · heise: Digitaler Kassenbon — PDF statt Zettelwirtschaft (Paywall)

3.2 Technischer Weg: App-Backend-APIs (dünne Faktenlage)

Ehrlich: zur Consumer-App-API gibt es öffentlich praktisch nichts. Was kursiert, ist durchweg etwas anderes:

Auth-Infrastruktur (das einzige harte technische Indiz): Sowohl Lidl als auch Kaufland fahren ihre Identity-Federation über NetIQ Access Manager (NIDP) unter Schwarz IT: federation.auth.lidl.com bzw. federation.auth.kaufland.com (beides /nidp/...-Endpoints), gemeinsame Staging-Domain federation-q.auth.schwarz. Das belegt gemeinsame Auth-Technik, nicht gemeinsame Konten. Der Lidl-Plus- App-Login läuft in unserem lidl.py zudem nicht über die NIDP-Federation, sondern über einen Duende-IdentityServer-OIDC auf accounts.lidl.com (/connect/authorize, /connect/token, client_id=LidlPlusNativeClient, PKCE, Scope openid profile offline_access lpprofile lpapis, Redirect com.lidlplus.app://callback). Kauflands App-Login wird sehr wahrscheinlich einem analogen OIDC-/PKCE-Muster folgen (eigener Host, eigene Client-ID, eigene Scopes) — aber das ist eine begründete Vermutung, kein bestätigter Fund.

Bot-Schutz: Bei Lidl bekannt: Akamai blockt python-requests → curl_cffi impersonate="chrome"; Fake-Header lassen Requests hängen. Schwarz nutzt gruppenweit ähnliche CDN/WAF-Schichten, daher ist bei Kaufland mit demselben Klassen-Problem zu rechnen (Akamai/Cloudflare-Fingerprinting). Unser curl_cffi-Wissen wäre hier der eine wirklich übertragbare Baustein.

Token-Lebensdauer/Refresh: unbekannt für Kaufland. Bei Lidl: rotierender refresh_token (lidl.py schreibt bei jedem Refresh neu). Plausibel analog, aber nicht belegt.

Fazit 3.2: Der App-API-Weg ist nicht recherchierbar, nur experimentell erschließbar — eine eigene mitmproxy-Session gegen die echte Kaufland-Android-App ist Pflicht, bevor irgendeine Zeile kaufland.py Sinn ergibt.

Quellen: GitHub-Topic kaufland · Marketplace Seller API (HMAC) · federation.auth.kaufland.com (NIDP) · federation.auth.lidl.com (NIDP) · Schwarz Digits / gemeinsame IT-Infra (CIO.de) · Schwarz Group (Wikipedia)

3.3 Bon-Detail-Format

Quellen: edekompile (Edeka-App-API, Bons als JSON) · heise: PDF-Bon

3.4 Vergleichbare Open-Source-Projekte

Händler Consumer-App-Bon-Client? Projekt
Lidl Ja Andre0512/lidl-plus (Python, OIDC, Bons als JSON) + Fork zsobix/lidlplus-api, titov-vv/lidl-plus-login, Android LittleMinus, LidlToGrocy
Edeka/Marktkauf/Scheck-in Ja ByteSizedMarius/edekompile (Go; Bearer aus Browser-Login → virtuelles Gerät → API-Credentials → Bons)
Kaufland Nein — nichts. Nur Marketplace-/Preis-Scraper.

3.5 Fallback-Wege ohne App-API

  1. PDF-Import via KI-Job (empfohlener Primärweg, nicht nur Fallback). Kaufland-Bon in der App als PDF exportieren → in Silverscale hochladen → neuer ai_jobs-Handler (Sonnet, Bild-/PDF-Input, eng begrenztes Tool-Set, ADR-13) extrahiert Positionen → schreibt in receipts/receipt_items (store='Kaufland'). Nutzt vorhandene Infrastruktur (Foto-Bon, Bild-Pipeline), null ToS-Risiko, sofort lauffähig.
  2. eBon per E-Mail: Bei Kaufland kein dedizierter E-Mail-Versand belegt (nur „speichern/teilen"). Über „Teilen → an eigene Mail" technisch möglich, aber manuell — kein Automatisierungs-Gewinn gegenüber PDF-Upload.
  3. Foto-Papierbon + KI: Fällt mit Weg 1 zusammen (gleicher Handler kann Foto und PDF). Sinnvoll, falls Card mal nicht gescannt wurde.
  4. DSGVO-Datenkopie (Art. 20): Kaufland muss auf Anfrage eine maschinenlesbare Kopie der Einkaufsdaten liefern (kundenmanagement@kaufland.de). Gut für einen einmaligen Historie- Bulk-Import, ungeeignet für laufenden Betrieb (Bearbeitungszeit Wochen).
  5. CSV-Export: kein offizieller CSV-Export bekannt.

Quellen: Kaufland Card Datenschutz / Betroffenenrechte · Kaufland Card Datenkopie-Kontakt

3.6 Rechtliches / Risiko (kurz)

4. Empfohlener Implementierungsweg

Phase A — PDF/KI-Bon-Import (jetzt, ~0,5–1 Tag)

Architektur (nutzt vorhandene Bausteine, neuer Code minimal):

Kaufland-App  ──(Dennis exportiert Bon als PDF)──►  Upload in Silverscale-UI
   │                                                   (neuer „Bon importieren"-Button
   │                                                    im Einkäufe-Tab, store-Auswahl)
   ▼
ai_jobs-Queue (ADR-13)
   neuer Handler "receipt_pdf":
   Sonnet, PDF/Bild-Input, Prompt = "extrahiere Positionen,
   Rabatte, Pfand, Gewichtsartikel, Steuersätze als JSON"
   ▼
importer.py  (vorhandene import_receipt-Logik wiederverwenden)
   r = {id: "KAUFLAND:<hash>", date, store:{name:"Kaufland"}, totalAmount, items[...]}
   ▼
receipts (store='Kaufland', in_inventory wie gewünscht)
receipt_items (name, unit_price, qty, is_weight, discount, tax_type, is_deposit)

Phase B — kaufland.py (später, nur falls Phase A nicht reicht)

  1. Recherche-Session am echten Traffic (separat, eigener Bericht ins Archiv): mitmproxy + Android-Emulator/Gerät mit Kaufland-App, Login + Bon-Abruf abfangen → Auth-Host, Client-ID, Scopes, Bon-Liste-/Detail-Routen, Format dokumentieren. Ohne diesen Schritt kein Code.
  2. kaufland.py als Klon der lidl.py-Struktur: login-CLI (Dennis macht Browser-Login + 2FA selbst, liefert Redirect-URL — feste Nie-automatisieren-Regel), refresh_token in .env (rotierend), curl_cffi impersonate="chrome" gegen Akamai, fetch-Befehl → gleiches receipts-JSON-Schema wie lidl.py ausgibt.
  3. importer.py --pull um eine --source kaufland erweitern (oder zweiter Cron-Eintrag), Idempotenz über Kaufland-Bon-IDs, store='Kaufland'.
  4. Cron analog Lidl (z. B. 07:50, gestaffelt nach dem Lidl-Pull 07:45).

Schema steht bereits Kaufland-tauglich: receipts.store (TEXT) und receipt_items (Name/Preis/Menge/Gewicht/Rabatt/Pfand/Steuer) brauchen keine Migration — Kaufland-Bons passen in die vorhandenen Spalten. art_id bleibt NULL (Lidl-spezifisch). foods.store kennt schon Mehr-Händler-Logik.

5. Aufwandsschätzung

Schritt Aufwand Risiko
Phase A: KI-PDF-Handler + Upload-UI + importer-Anbindung 0,5–1 Tag gering (KI-Genauigkeit; mit Bestätigungs-Dialog abgefedert)
Phase B.1: mitmproxy-Recherche Kaufland-App 0,5–1 Tag (ergebnisoffen, kann scheitern) mittel (Cert-Pinning? Akamai?)
Phase B.2–4: kaufland.py + Cron + Parser (wenn B.1 klappt) 1–2 Tage mittel (ToS/Sperre, API-Bruch jederzeit)

Empfehlung: Phase A bauen, Phase B nur bei echtem Bedarf (Kaufland wird regelmäßiger Einkaufsort). Phase A liefert 90 % des Nutzens für 20 % des Aufwands und null Risiko.

6. Risiken

7. Offene Fragen an Dennis (max. 3)

  1. Wie oft kauft ihr bei Kaufland ein? Selten → Phase A (PDF-Upload) reicht dauerhaft. Regelmäßig → Phase B (Auto-Pull) lohnt die Recherche-Session.
  2. Habt ihr eine Kaufland Card mit aktiviertem digitalem Bon? (Voraussetzung für beide Wege — sonst nur Foto vom Papierbon.)
  3. Phase B überhaupt gewünscht? Sie braucht eine eigene mitmproxy-Recherche- Session und akzeptiert ein kleines Konto-Sperr-Risiko — oder bleiben wir bewusst beim risikofreien PDF/KI-Weg?

8. Nachtrag (07.06.2026 abends): Phase B getestet → Cert-Pinning

Dennis wollte Phase B und hat — wie beim eGYM-Capture — eine mitmproxy-Session mit dem iPhone 16 gefahren. Befund eindeutig: Die Kaufland-App betreibt Certificate Pinning auf ihren kritischen Hosts.

server connect app.kaufland.net:443   → Client TLS handshake failed.
                                         The client disconnected during the handshake.
server connect account.kaufland.com:443 → dito (konsequent)

Gleichzeitig liefen 1Password, Amazon Music, Outlook sauber durch denselben Proxy → das mitm-Cert war korrekt installiert und vertraut. Die App prüft zusätzlich selbst die Server-Identität und bricht ab, sobald ein Proxy dazwischensteht. app.kaufland.net ist die eigentliche Bon-/API-Domain, account.kaufland.com die Auth — beide gepinnt, also kein passiver Capture möglich (anders als Netpulse/eGYM, das nicht pinnte).

Plan-C-Optionen (für eine etwaige spätere Phase B): - iOS-Unpinning: Kaufland-IPA + Frida-Gadget/objection einbauen, mit dem Apple-Dev-Account neu signieren, per SideStore installieren → dann Capture. - Android-Unpinning: Emulator + apk-mitm/objection (kein Signing-Tanz, oft robuster).

Entscheidung Dennis (07.06.2026): Phase B vertagt, wir bauen Phase A (PDF-Upload → KI-Extraktion). Deckt das Ziel (Kaufland-Bons im Archiv/Vorrat) ohne Pinning-Kampf und ohne ToS-Risiko ab. → Umsetzung in ADR-52.