I hope REWE is seeing this and offers an official MCP server. In the end we pay real money there. :D
I wrote a skill some time ago to support me with "agentic groceries" on my own - it's the future of shopping I would say.
My workflow:
- I paste in urls or text for receipts I will cook this week
- agent extracts the ingredients, calculates cups to ml and such, replaces meat with vegi ingredients, replaces some other things I prefer always (often also creates a nice markdown receipe at this steo I can put into Obsidian)
- check my list of favs, check search cache (so not every time the api is called, I'm a good netizen :D )
- ask me which items I have at home (no need to add to the basket)
- search rewe api for multiple candidates and let me choose.
- after each recipe I enter /new to start with fresh context
- also I have a list of things I buy every week
I still put everything manually in the basket in the end, but this is not the thing which is time intensive.
This is also my exact workflow here. Thank you. I'm adding things that should be in the basket via Siri to my Obsidian notes. I also add recipes to that list or anything else. Then Claude checks that list once I want to do the shopping, looks through my favorites, and fills the baskets with all the items needed. I also use Claude to list the most frequently bought items for a template that always gets filled in.
It is extremely simple. I just tell Claude: "Use korb to look at my order history and create a table with my most frequently bought items. Next time, fill my basket with the items I always buy."
So something of that variation works.
I do have a suggestion for your app though:
Have it compare your basket of goods across different markets in your region to show you the cheapest option.
I'm pretty sure this possibility is actually one of the reasons they locked down the API.
I've used Data from REWE in the past and made a comparison between a couple of cities in Germany (I believe it was Frankfurt, cologne, Berlin, Munich and Hamburg). Hamburg was by far the most expensive, often as much as 10-20% more expensive.
> The suggestion engine (korb suggestion threshold) is re-implemented in Lean 4 with five mathematically proven properties: suggestions have positive frequency, are sorted descending, come from ordered and available products, exclude basket items, and respect the count limit.
This is amazing. I mean this literally in that I am amazed, but also figuratively in that I am delighted to watch the type-safe-mad build cool shit.
As a SWE at Rewe (at a completely different department), I can say that I find this pretty cool. I wonder if this is going to be a wakeup to management to relax the API restrictions.
I want to add something else to this. In the process of writing this, I also played with formal verification and formally verified the suggestion engine, which was a really nice side discovery.
The basic idea is to write a prove in Lean4 and then test both the production implementation (Haskell) and the Lean implementation against random inputs.
Compare if the results are the same.
If that is the case -> you can be pretty sure the unproven production version is as correct as the proven lean version.
Surprised how little the B2C and even B2B e-commerce segment is providing API access for automation and agentic coding. One could easily set up rate limits, fraud detection and KYC checks upfront initial access.
I love the idea of a CLI for groceries. Do you have plans to support 're-order' scripts or meal-plan integration? I can imagine a workflow where a recipes.yaml file gets piped into your CLI to automatically fill the cart with everything needed for the week. Much faster than clicking through a mobile UI.
I remember a friend and I in college were looking into ways to do this in the US but major grocery chains here are pretty sensitive about their product data being accessible by open APIs and web scraping...
Really cool to see things still being built in Haskell! How do you find using it compared to some of the newer languages that have more modern tooling?
Did you implement your own OAUTH2 flow in haskell for this?
I want to use this but I literally have a Rewe 20 meters (at most) from the entrance to my building. Still I might give it a go considering all the positive comments in the thread.
been ordering from REWE for years =) always wished the app was less annoying. all my programm skills - for what? lol. probs for reverse engineering the mTLS part, most people would have just given up.
how stable this is in practice? Internal APIs tend to break without warning when they update the app.
85 comments
I wrote a skill some time ago to support me with "agentic groceries" on my own - it's the future of shopping I would say.
My workflow:
- I paste in urls or text for receipts I will cook this week - agent extracts the ingredients, calculates cups to ml and such, replaces meat with vegi ingredients, replaces some other things I prefer always (often also creates a nice markdown receipe at this steo I can put into Obsidian) - check my list of favs, check search cache (so not every time the api is called, I'm a good netizen :D ) - ask me which items I have at home (no need to add to the basket) - search rewe api for multiple candidates and let me choose. - after each recipe I enter /new to start with fresh context - also I have a list of things I buy every week
I still put everything manually in the basket in the end, but this is not the thing which is time intensive.
Also there already exists this reverse engineered project: https://github.com/ByteSizedMarius/rewerse-engineering/
I do have a suggestion for your app though: Have it compare your basket of goods across different markets in your region to show you the cheapest option. I'm pretty sure this possibility is actually one of the reasons they locked down the API.
I've used Data from REWE in the past and made a comparison between a couple of cities in Germany (I believe it was Frankfurt, cologne, Berlin, Munich and Hamburg). Hamburg was by far the most expensive, often as much as 10-20% more expensive.
I really like your suggestion. I will put it in an issue and look into that. https://github.com/yannick-cw/korb/issues/4
It can search for items, add them to the basket, picks a delivery slot and does the checkout.
With a little more scaffolding in markdown files, this now takes care of my weekly shopping.
The basic idea is to write a prove in Lean4 and then test both the production implementation (Haskell) and the Lean implementation against random inputs. Compare if the results are the same.
If that is the case -> you can be pretty sure the unproven production version is as correct as the proven lean version.
https://www.dev-log.me/formal_verification_in_any_language_f...
Haskell is indeed an interesting choice. ;)
> Finally the best side projects are the ones you actually use and this one will be used for all my future grocery shopping.
Until it breaks in a few weeks.
It would have been a cool project!
Did you implement your own OAUTH2 flow in haskell for this?
how stable this is in practice? Internal APIs tend to break without warning when they update the app.