Zuletzt aktualisiert:

EAN/GTIN für Lidl-Plus-Bons – Recherche-Bericht

Stand: 05.06.2026 · Recherche: 2 parallele Web-Recherchen + eigene Live-Tests gegen die Lidl-APIs (mit echtem Konto/Token)

Kernbefund

Die Aussage „die Mobile-App-API liefert die EAN mit" war richtig – ist aber seit Q3/2024 tot. Das v2-Bon-Detail (tickets.lidlplus.com/api/v2/…/tickets/{id}) lieferte pro Position das Feld codeInput = EAN-13. Lidl hat diesen Endpoint serverseitig abgeschafft; der Nachfolger v3 liefert den Bon nur noch als gerendertes HTML (ticketType: "HTML") mit der internen 7-stelligen Artikelnummer (data-art-id) – ohne EAN. Es gibt Stand Juni 2026 keinen bekannten API-Weg mehr zur EAN pro Bon-Position. Die gesamte Reverse-Engineering-Community bestätigt das; O-Ton aus dem maßgeblichen Projekt (lidl-plus PR #22, 10/2024):

"unfortunately yeah, there's no way to get the barcode now."

Konsequenz: Die EAN muss außerhalb der Lidl-API beschafft werden (OpenFoodFacts-Matching, Selbst-Scannen). Genau dafür ist unser Hybrid-Ansatz gebaut – Details unten.

1. Eigene Live-Befunde (mit echtem Token verifiziert, 05.06.2026)

Endpoint Ergebnis
GET api/v2/DE/tickets (Liste) ✅ funktioniert (467 Bons)
GET api/v2/DE/tickets/{id} (das alte EAN-Detail) ❌ 405, Allow: DELETE – Lesen abgeschaltet
GET api/v3/DE/tickets/{id} ⚠️ 200, aber ticketType:"HTML" – nur data-art-id, kein codeInput, keine 13-stellige Zahl im gesamten HTML
GET api/v1|v4/DE/tickets/{id} ❌ 404
v3 mit App-Headern / ?format=json u. ä. ❌ identisches HTML, kein JSON-Schalter
appgateway.lidlplus.com/app/V24|v24|v23/DE/tickets… (Spur aus alter Postman-Doku) ❌ 502 Bad Gateway – Route existiert nicht mehr
www.lidl.de/p/x/p0081315 (Bon-artId als Shop-ID) ❌ 404 – Bon-Artikelnummer ≠ lidl.de-SKU, kein Mapping
Header App-Version: 999.99.9 ⚠️ triggert Akamai (Request hängt bis Timeout) – Fake-App-Header vermeiden

2. Geprüfte Spuren aus der Web-Recherche

Tot (belegt)

Offen mit gedämpfter Erwartung

Nutzbar (und teils schon umgesetzt)

3. Was bereits gelöst ist (unser Hybrid-System, Stand heute)

  1. Stabiler Schlüssel statt EAN: jede Bon-Position wird über die interne Artikelnummer als Grocy-Barcode LIDL:{artId} getrackt – Import, Preishistorie und Idempotenz funktionieren ohne EAN.
  2. Auto-Anreicherung: OFF-Namenssuche mit Lidl-Eigenmarken-Boost; bei Konfidenz ≥ 0.75 werden Klarname, echte EAN, Kategorie und kcal/Makros übernommen → ~40 % der 968 Produkte exakt angereichert.
  3. Fuzzy-Makros: sync.py enrich --fuzzy übernimmt bei Konfidenz ≥ 0.6 nur die Nährwerte vom besten Namenstreffer (gleichnamige Produkte anderer Marken sind nährwertlich nahezu identisch); kein Umbenennen, keine falsche EAN.
  4. Nachschärfen per Scan: echte EAN einmal mit der Grocy-App ans Produkt scannen → sync.py enrich überschreibt mit den exakten OFF-Daten. Die Kandidatenliste liefert sync.py status.
  5. Duplikate: Lidl vergibt pro Produkt mehrere Artikelnummern → sync.py dedupe führt sie zusammen (52 Stück bereits gemergt), der Import verhindert neue Duplikate über die gematchte EAN.

4. Empfohlene nächste Schritte

Prio Maßnahme Erwartung
1 OFF-Matching verschärfen: stores_tags=lidl-Vorfilter + Kategorie→Eigenmarken-Heuristik in best_match() +10–20 pp automatische Abdeckung, exaktere EANs
2 Nachscannen im Alltag (Top-Produkte zuerst: sync.py status sortiert nach Konfidenz) 100 % exakt für alles, was du tatsächlich kaufst
3 DSGVO-Kopie anfordern und auf GTIN prüfen gering, aber gratis
4 (optional, exotisch) Scan&Go-MITM in einem Lidl-&-Go-Markt hoch riskant/aufwändig, einzige echte artId↔EAN-Brücke

5. Update 16.06.2026 — IPA-Static-Analyse geprüft, EAN-Bridge geparkt

Terra (Foundation) hat die entschlüsselte Lidl-Plus-IPA v17.3.6 statisch zerlegt (Hermes-Bytecode-Disasm + Mach-O-Strings aus Haupt-Binary + 26 Frameworks) plus einen Live-MITM-Versuch. Roh-Korpus: /home/dennis/lidl-re/ (README = Methodik, analysis/strings_*, captures/). Distillat: /home/dennis/foundation/vpn/lidl-api.md. Ergebnis für unser Bon-EAN-Problem: bestätigt den Kernbefund oben, keine neue Brücke. Im Detail (eigene Live-Tests + Korpus-Grep, 16.06.):

Entscheidung (Dennis, 16.06.): EAN-Bridge geparkt, bis es eine Live-Aufnahme gibt. Produktiver Weg bleibt das OFF-Matching (§3). Nicht erneut blind von der VPS gegen product-catalog probieren — ohne live gesehenen Pfad + passende productId ist das aussichtslos. (Potenziell wertvoller als die EAN-Bridge wäre Use-Case A: Live-Einkaufslisten-Abhaken via selfscanning/basketsummary — ebenfalls gepinnt, braucht dieselbe Live-Capture-Session.)

Quellen