Zuletzt aktualisiert:

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-Wxxweeks[].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/loginaccess_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

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)

  1. JWT einmalig manuell ablegen (Secret-File, 0600).
  2. past-deliveries → Rezept-IDs der eigenen Boxen (einziger Token-Schritt).
  3. Pro ID öffentliche Rezeptseite holen, __NEXT_DATA__ defensiv parsen.
  4. Mapping: Zutaten-Produkte per Name matchen/anlegen (wie Lidl-Sync), Einheiten auf Grocy-qu_id mappen, Rezept + Positionen anlegen, Nährwerte in description.
  5. 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