How it works
The brain lives on Mealio. The hands live on the phone. Here is what that means for you and your users.
The relay
The SDK is small and generic. It holds a hidden WebView signed in to the user's store, and it can load a page, run a script in it, show a sign-in sheet, or make a request. Mealio's server decides every step: what to search, which options to offer, what to add. Each step reaches the phone as a signed instruction, and the SDK sends back what the store answered.
That design is why a store change is fixed on Mealio's side with no update to your app, and why new stores appear without you shipping anything.
Safety built into the SDK
| Protection | What it does |
|---|---|
| Signed instructions | Every instruction is signed with Mealio’s Ed25519 key. The SDK verifies it before running anything and refuses expired, replayed or out-of-order steps. |
| Allowlist | The SDK only talks to the store’s own domains over HTTPS. The list ships inside the SDK, so the server cannot turn it off. |
| No checkout, ever | Checkout, payment, billing, order and account-security pages are blocked inside the SDK, for page loads and for requests made from the page. |
| Rate caps | The SDK caps requests per store, whatever it is told. |
| Your keys | Your secret key stays on your server. Sessions last 15 minutes and belong to one user. |
What Mealio stores
Your external user id, the products each user chose per recipe, cart results, and for Kroger family users an encrypted Kroger connection. Store responses are read during a run and are not kept. Mealio never sees or stores store passwords.DELETE /api/v1/users/{id} removes everything for a user.
Choices
Users choose every product. Mealio reuses a choice only for the same recipe at the same store, and only when that product is in stock. Options are ranked using the user's picks in other recipes and anonymous counts of what other Mealio users pick. Rankings change the order of options. They never add anything.