Phase 5 – HelloFresh → Grocy (Recherche, Stand 05.06.2026)
Keine offizielle API, aber zwei funktionierende inoffizielle Wege (beide Anfang 2026 verifiziert). Empfehlung: Hybrid – interne API nur für die Liste der eigenen Lieferungen, Inhalte von den öffentlichen Rezeptseiten.
1. Interne Gateway-API (für EIGENE Lieferungen)
Erreichbar als Pfad-Präfix auf der normalen Domain (https://www.hellofresh.de/gw/),
nicht gw.hellofresh.com direkt. Auth: Authorization: Bearer <JWT>.
Verifizierte Endpoints (Quelle: CNoetzel/HelloFresh-RecipeDownloader, gepflegt, letzter Push 02/2026):
| Zweck | Endpoint |
|---|---|
| Eigene Abos | GET /gw/api/customers/me/subscriptions |
| Vergangene Lieferungen | GET /gw/my-deliveries/past-deliveries?subscription=<id>&from=2026-Wxx → weeks[].meals[].id |
Rezept-Detail (inkl. cardLink = PDF) |
GET /gw/recipes/recipes/<recipeId> |
| Rezept-Suche | GET /gw/recipes/recipes/search?country=DE&locale=de-DE&q=…&skip=0&take=16 |
| PDF-Rezeptkarte | https://hellofresh.com/recipecards/card/<slug>-<id>-<hash>.pdf |
Token: manuell aus dem Web-Login ziehen (F12 → Network → /gw/login →
access_token). JWT ist kurzlebig, kein Refresh bekannt → fragilster Teil; für
Cron entweder Erneuerung automatisieren oder diesen Schritt selten/manuell laufen
lassen. (Das alte auth/token-Schema mit client_id/secret aus hpufo/HelloFresh ist
ein Coding-Challenge-Relikt, nicht der reale Kundenweg.)
2. Öffentliche Rezeptseiten (für INHALTE – empfohlen)
https://www.hellofresh.de/recipes/<dish-slug>-<24-char-objectId> – die ObjectId ==
meal.id aus der Delivery-API, beide Wege koppelbar. Slug optional (Redirect).
Live an DE-Seite verifiziert: vollständige Zutaten mit Menge+Einheit („400 g
Kartoffeln", „10 ml Senf") und komplette Nährwerte pro Portion (kcal, Protein,
Fett, KH, Ballaststoffe, Salz …), Portionsgröße, Zeiten, Schritte. Alles im
__NEXT_DATA__-Blob (Next.js). JSON-LD ist unzuverlässig → nicht verwenden.
Anti-Bot: aktuell kein Cloudflare/Akamai-Gate; plain requests mit realistischem
User-Agent + Rate-Limit (1 Req / 2–3 s) genügt. curl_cffi als Fallback bereithalten.
3. Bestehende Projekte
CNoetzel/HelloFresh-RecipeDownloader(Python, aktiv): beste Referenz für Delivery-API + PDF-Download. Parst keine strukturierten Daten, Token manuell.hhursev/recipe-scrapers(aktiv): HelloFresh-Support nur rudimentär (Zeiten aus__NEXT_DATA__, Rest JSON-LD-Basisklasse → auf HelloFresh dünn; alter Mengen-Halbierungs-Bug #527).alexcodito/HelloFreshCrawler(Node, 2024): crawlt öffentliche Archive/PDFs.- Tandoor/Mealie: kein funktionierender HelloFresh-Import;
hellofresh-to-grocyexistiert nicht. → Eigenbau nötig, wie bei Lidl.
4. Grocy als Ziel
Kein dedizierter Recipe-Import, aber generische Objects-API:
- POST /api/objects/recipes (name, description, base_servings, …)
- POST /api/objects/recipes_pos (recipe_id, product_id, amount, qu_id, …)
– Achtung grocy#1528: Mengenumrechnung bei Non-Stock-Einheiten testen.
- Nährwerte sind kein First-Class-Rezeptfeld → in description (Markdown) oder
Userfields ablegen.
5. Empfohlener Bauplan (wöchentlicher Cron)
- JWT einmalig manuell ablegen (Secret-File, 0600).
past-deliveries→ Rezept-IDs der eigenen Boxen (einziger Token-Schritt).- Pro ID öffentliche Rezeptseite holen,
__NEXT_DATA__defensiv parsen. - Mapping: Zutaten-Produkte per Name matchen/anlegen (wie Lidl-Sync), Einheiten auf
Grocy-
qu_idmappen, Rezept + Positionen anlegen, Nährwerte indescription. - Idempotenz über Rezept-IDs, niedrige Frequenz, Retries.
Risiken: JWT-Ablauf (a), ToS/Account-Risiko bei aggressivem Scraping (b),
__NEXT_DATA__-Schemaänderungen (c), Einheiten-Mapping (d), künftiges Anti-Bot (e).
Quellen
- https://github.com/CNoetzel/HelloFresh-RecipeDownloader
- https://github.com/hpufo/HelloFresh/blob/master/USE_THE_API.md
- https://github.com/hhursev/recipe-scrapers (+ Issue #527)
- https://github.com/alexcodito/HelloFreshCrawler
- https://www.hellofresh.de/recipes/
- https://github.com/grocy/grocy/issues/544 /983 /1528
- https://github.com/grocy/grocy/blob/master/grocy.openapi.json