Daniel has been running a home inventory system for years, born from the frustration of spending an hour hunting for a specific screwdriver. Now he’s asking a deceptively simple question: if the inventory is already digital and checked weekly, why can’t the system just reorder toilet paper when it hits the par level? The answer reveals a strange truth about supermarket APIs — they exist, but they’re not for consumers. Walmart has a developer API for product search and inventory, but it lacks an order placement endpoint. The ordering side is reserved for sellers and marketplace partners. Tesco in the UK once had a full ordering API, but it was deprecated around 2018, likely due to fraud vectors like delivery slot scalping and payment testing. The pattern is consistent: grocery fulfillment is hard, substitutions are inevitable, and the support burden of thousands of automated agents is something no supermarket wants to shoulder. That’s why the closest consumer solution is Amazon’s walled garden — Dash buttons and Alexa reordering work because Amazon controls every layer. But the most interesting development in mid-2026 is the agentic AI angle. Instead of asking for a structured API, AI agents can now navigate a supermarket website like a human, using browser automation frameworks driven by LLMs. They see buttons and form fields visually, clicking “Add to Cart” without caring about CSS changes or A/B tests. The website itself becomes the API — undocumented and unstable, but usable. This flips the question from “which supermarkets expose an API” to “which supermarkets have a website stable enough for an agent to navigate.” While the technical capability is advancing fast, it raises unresolved questions about terms of service, liability, and what happens when an agent accidentally orders forty cases of paper towels.
#3684: Your Home Inventory Can’t Order Groceries (Yet)
Supermarkets have APIs, but they’re not for you. Here’s how AI agents are changing the game.
Episode Details
- Episode ID
- MWP-3863
- Published
- Duration
- 28:21
- Audio
- Direct link
- Pipeline
- V5
- TTS Engine
-
chatterbox-regular - Script Writing Agent
- deepseek-v4-pro
AI-Generated Content: This podcast is created using AI personas. Please verify any important information independently.
Downloads
Transcript (TXT)
Plain text transcript file
Transcript (PDF)
Formatted PDF with styling
You Might Also Like
Never miss an episode
New episodes drop daily — subscribe on your favorite platform
New to the show? Start here#3684: Your Home Inventory Can’t Order Groceries (Yet)
Daniel sent us this one — he's been running a home inventory system for years, started because he couldn't find a specific screwdriver without an hour of hunting, and now he's wondering: if the inventory is already digital, and we check it weekly, why can't the whole thing just reorder itself when toilet paper hits the par level? The problem is that'd require a supermarket with an API accessible to regular consumers. He's asking whether any supermarket chains actually expose an API for automated ordering, what those APIs tend to look like, and how payment gets handled in automated fulfillment.
This is one of those questions where the real answer is considerably weirder than the question anticipates. Because there are supermarket APIs. There are actually quite a few of them. They're just not for us.
They're for the chosen ones.
They're for commercial partners, delivery aggregators, and in a few cases, enterprise customers. But consumer-facing? The closest thing in North America is probably Walmart's Developer API — they have one, it's been around for years, and it does expose product search, inventory lookup, and pricing. But here's what it doesn't do: let you place an order. That endpoint isn't there. The ordering side is handled through their marketplace APIs for sellers, not buyers.
It's a catalog, not a checkout.
It's a window-shopping API. You can ask it whether the store on route seven has paper towels in stock, but you can't say "send me twelve rolls.
Which is the whole point of the exercise. That's like a car with no engine.
The reason gets at something fundamental about grocery e-commerce. Grocery fulfillment is genuinely hard in ways that don't apply to, say, ordering a book. Fresh inventory turns over daily. Substitutions are inevitable. Delivery windows are tight. The last mile is expensive and logistically punishing. Most supermarkets don't want to expose that complexity through an API because the support burden would be enormous. Imagine thousands of automated agents all placing orders, each one generating substitution exceptions for a different brand of almond milk.
The agent doesn't know you're picky about almond milk.
The agent knows the SKU. It doesn't know you'll be furious if they swap in oat milk. That's a human judgment call that the current API surface just isn't designed to handle.
The API exists, but it's gated behind a commercial agreement because they want a human — or at least a known partner — on the other end who'll eat the support cost.
That's the Instacart model, actually. Instacart does have an API, but it's strictly for retail partners. If you're Kroger or Costco or whatever, you integrate with Instacart's platform to manage your catalog and pricing. The end consumer never touches it. There's no public endpoint that lets you say "place an order to be fulfilled by Instacart from the nearest Safeway." It's all mediated through Instacart's own app and website.
The API is B2B, not B2C. Business to business. The consumer is deliberately kept out.
That's the pattern across the board. Amazon Fresh — no public ordering API. Amazon has a vast API ecosystem, but the Fresh and Whole Foods ordering is locked down. Tesco in the UK had a developer API years ago that did include ordering, but they deprecated the consumer-facing parts around twenty eighteen. I'm not sure about current status, but as of the last public documentation I could find, the ordering endpoints were gone.
Wait, Tesco had one? Tesco, like — the British supermarket?
The very same. They were actually ahead of the curve on this. Their API let you search products, manage a basket, and place an order programmatically. It was part of a broader push into what they called connected commerce. But they pulled back. The official line was about refocusing on the core app experience, but reading between the lines, I think the fraud and abuse vectors were significant.
What kind of abuse are we talking about?
Automated scalping of delivery slots, for one. In the UK during COVID, delivery slots were scarce, and there were reports of bots snatching them up. An open ordering API would make that trivially easy. Plus there's the payment fraud angle — if you can place orders programmatically, you can test stolen card numbers with real transactions.
The API died for our sins. Specifically, the sin of being terrible to each other during a pandemic.
A recurring theme, honestly. But here's where it gets interesting — and this connects directly to the second part of the prompt about what these APIs actually look like. When they do exist, even in B2B contexts, the structure is surprisingly consistent. You typically see a product catalog endpoint, an inventory availability endpoint, a basket or cart management endpoint, an order submission endpoint, and one or more endpoints for order status and tracking. The cart is usually server-side — you create a cart object, add line items to it, and then submit it. Payment is almost always tokenized.
Tokenized meaning — you don't send credit card numbers through the API.
You either pre-register a payment method and get back a token, or you use a third-party tokenization service like Stripe or Braintree. The actual payment processing happens through a separate gateway. The ordering API just says "charge token ABC123 for order DEF456." It never sees the card number.
Which is smart architecture, but also makes it harder for a homebrew system to just plug in. You need a token. You need a merchant account somewhere. You can't just POST a credit card number to the supermarket.
That's the second big barrier. Even if the API existed, the payment plumbing is non-trivial for an individual. You'd need to be PCI compliant, or at least PCI-adjacent enough not to get your token revoked. Which is why most of the automated replenishment systems that do work in the consumer space don't go through supermarket APIs at all.
They go through Amazon.
They go through Amazon. The Dash buttons were the obvious example — physical buttons you'd stick around your house, press when you're low on something, and it'd order through your Amazon account. Those used a private API, obviously. Then they moved the same logic into Alexa — you can say "Alexa, reorder toilet paper" and it'll pull from your order history and place the order. But it's all within Amazon's walled garden.
The Dash buttons themselves are dead now, right?
Discontinued in twenty nineteen, though the virtual Dash equivalent still exists in the Alexa app and on some smart displays. But the point is, Amazon built the whole stack — the button, the ordering logic, the payment, the fulfillment — because they control every layer. They don't need to expose an API to you because they own the entire vertical.
The consumer API for automated grocery ordering is basically "be Amazon's customer and use their interface." Which is not an API in the sense Daniel is asking about. That's a voice command to a proprietary system.
That brings us to the most interesting part of the question, which is the agentic AI angle. Because what's actually happening right now — and this is where mid twenty twenty-six gets weird — is that the API question might be asking the wrong thing.
An API is a structured interface designed for programmatic access. It expects you to speak its language — specific endpoints, specific parameters, specific authentication. But an AI agent doesn't necessarily need an API. It can use the same interfaces humans use. It can navigate a website, fill in forms, click buttons, handle the checkout flow. The whole point of agentic AI is that it interacts with systems the way a person would.
Instead of calling "POST bar soap endpoint" with a JSON payload, it just goes to the supermarket website and buys the soap.
And this is already happening, just not in the way most people think. There are browser automation frameworks — Puppeteer, Playwright, Selenium — that have been around for years. What's new is that LLMs can now drive them with a reasonable degree of reliability. An agent can look at a web page, understand its structure visually and semantically, locate the search bar, type in "toilet paper," select the right product, add it to cart, navigate checkout, and complete the purchase.
The API is the DOM. The website itself becomes the interface.
The website becomes the API. It's an undocumented, unstable, constantly-changing API that was never designed to be consumed by machines, but it's there, and agents can use it.
Which is simultaneously brilliant and horrifying.
It's the ultimate undocumented endpoint. Every supermarket with a website has accidentally built an API — it's just an API designed for human eyes and human click patterns, and the agent has to reverse-engineer it in real time.
"Accidentally built an API" is going to be the subtitle of the twenty twenties.
I think that's right. And it flips the whole question on its head. Instead of asking "which supermarkets expose an API," the relevant question becomes "which supermarkets have a website stable enough for an agent to navigate reliably.
The answer to that is — none of them, currently. Websites change constantly. A CSS class gets renamed, a checkout flow gets A/B tested, and suddenly your agent is trying to click a button that no longer exists.
That's the fragility problem. But it's getting better fast. Computer use capabilities in models like Claude — and I should note, we're talking about the model from Anthropic, the friendly AI down the road — are getting remarkably good at handling these variations. They don't rely on specific CSS selectors. They see the page more like a human does, recognizing buttons and form fields by their visual and semantic properties rather than their underlying markup.
You're saying the agent doesn't care if the "Add to Cart" button changes from blue to green or moves three pixels to the left.
It doesn't care about any of that. It sees a button that says "Add to Cart" and clicks it. The same way you would. The brittleness of traditional web scraping — where a single class name change breaks everything — doesn't apply in the same way.
Which means the supermarket doesn't need to build an API. The agent adapts to whatever the supermarket puts in front of it.
This is actually a better model for the supermarket, because they don't have to maintain a separate API surface, they don't have to worry about rate limiting or authentication tokens for third parties, and they don't have to handle the support burden of "your API returned a five hundred error on my automated toilet paper order." The transaction looks identical to a human purchase.
Except it's not a human. And that raises questions about terms of service, about whether automated purchasing is allowed, about what happens when the agent accidentally orders forty cases of paper towels because it misread the quantity selector.
All real problems. And I think this is where the agentic AI enthusiasm needs to be tempered with some practical reality. Even if the technical capability exists — and it increasingly does — there's a whole layer of policy, liability, and error handling that hasn't been figured out yet.
Let's actually walk through what an automated replenishment system would look like today, in practice, for a home user who wants to solve the toilet paper problem. What are the actual pieces?
So step one, you have your inventory system. Daniel's already done this — he's got an open source home inventory tracker, he's got par levels defined, he's doing weekly checks. That's the foundation.
Which is more than most warehouses had in nineteen eighty, so we're already ahead.
Step two, you need a trigger. Inventory drops below par, something needs to notice. In a professional warehouse, this is often weight sensors in the bins — the system knows a bin of screws weighs twelve pounds when full, and when it drops to three pounds, it's time to reorder. For a home user, that's overkill. But you could use a simpler trigger — a weekly check where you scan a barcode or tap a button in an app that says "I'm low on this.
Or even just a scheduled script that checks the inventory database and flags anything below par.
Step three is the ordering action. And this is where it forks. Option A: you use an existing subscription service. Amazon Subscribe and Save is the obvious one — it's not API-driven from your end, but it is automated replenishment. You set a schedule, they ship on the schedule, done. Option B: you use an agent to place orders on a supermarket website. Option C: you find a retailer that does have an API, which as we've discussed is mostly B2B but there are some edge cases.
What edge cases?
Wholesale suppliers, mostly. If you're willing to buy in bulk, restaurant supply companies and wholesale distributors like Sysco or US Foods have ordering platforms that are much more API-friendly. But you're buying a case of forty-eight toilet paper rolls, not a six-pack.
Which for a family home might actually make sense, depending on storage space.
And there's another category: meal kit services and specialty food delivery. Companies like Blue Apron, HelloFresh, and some of the direct-to-consumer food brands do have APIs because their whole business model is recurring automated ordering. But that's a specific niche — you're not ordering toilet paper from Blue Apron.
Though I'm sure someone has tried.
Someone has definitely tried. But the broader point is that the API landscape for consumer grocery ordering is essentially empty. What exists is either B2B or locked inside walled gardens like Amazon. The action isn't in APIs — it's in agents that can navigate the human-facing web.
Which brings us to payment. How does the agent actually pay?
This is where it gets practically tricky. The agent needs a payment method. In most cases, that means it needs access to your credit card information, or more realistically, to a stored payment method in whatever platform it's using. If you're going through Amazon, the payment is already handled — your card is on file, the agent just needs to authenticate and complete the order.
If the agent is navigating a supermarket website, it needs to either have your card details or use some kind of payment token.
Storing raw credit card details in a home automation script is a spectacularly bad idea from a security standpoint. That's how you get your card number leaked through a misconfigured backup or a compromised device. The right way to do it would be through a payment token — something like a virtual card number with spending limits, or a token from a payment processor that's scoped to a specific merchant and amount range.
Do consumer banks even offer that?
Privacy dot com is a service that generates virtual debit cards with per-merchant and per-transaction limits. Capital One has Eno, which generates virtual card numbers. Revolut has disposable virtual cards. These are designed exactly for this kind of use case — you create a card that can only be used at, say, walmart dot com, with a monthly limit of fifty dollars, and if that card number leaks, the damage is contained.
The payment layer exists. It's just not integrated into the grocery ordering flow in a clean way yet.
The pieces are all there, they're just not assembled. And that's really the story of this whole space. The inventory management exists. The agent capabilities are emerging. The payment tokenization exists. But nobody has put them together into a consumer product that says "scan your pantry, set your par levels, and we'll handle the rest.
This seems like an obvious startup opportunity.
I think there are three reasons. One, the margin on grocery delivery is already razor-thin, and adding an automation layer doesn't create much additional value you can capture. Two, the error cost is high — if your automated system accidentally orders three hundred dollars of perishable food, who eats that cost? Three, most people don't actually want to manage a home inventory system. The friction of "I'm out of toilet paper, I'll add it to my next grocery run" is low enough that automating it doesn't feel urgent.
That's the real answer, isn't it? The pain point isn't painful enough.
For most people, no. The prompt mentions it took an hour to find a specific screwdriver. That's a real pain point for someone with lots of specialized equipment. But for household consumables, the pain point is "I need to remember to buy toilet paper," which is solved adequately by a shopping list.
Though I'd argue there's a subtlety here. The pain point isn't remembering to buy toilet paper. It's the cognitive load of tracking dozens of household consumables at different depletion rates. Toilet paper runs out slowly and predictably. Dish soap runs out at a different rate. Light bulbs are completely unpredictable. Keeping mental inventory of all of that is taxing.
That's fair. And it's the argument for automated replenishment — it's not about any single item, it's about the aggregate mental overhead of household inventory management. The same reason warehouses don't rely on workers noticing when shelves are empty.
The cost of a touch.
Every time you have to think "am I low on this," that's a cognitive touch. And touches add up.
We've established that supermarket APIs for consumers basically don't exist, and the agentic approach of navigating websites is technically feasible but not yet productized. What about the third path — the wholesale supplier route? If someone really wanted to automate this today, could they just order in bulk from a supplier that does have an API?
They could, with some caveats. Restaurant supply companies like WebstaurantStore have fairly comprehensive ordering systems, though I haven't confirmed they expose a public API. But the model is different — you're buying commercial quantities, you need a business account, and the product selection is industrial. Your toilet paper will be the kind that comes in giant rolls for commercial dispensers.
Which is arguably better toilet paper, honestly.
But the real issue is storage. A case of commercial toilet paper is roughly the size of a small refrigerator. Most apartments in Jerusalem don't have space for that.
So wholesale works if you have a basement or a garage, but not for apartment living.
That's the physical constraint that shapes the whole problem. Automated replenishment works beautifully in warehouses because warehouses are designed around storage density. A home is not a warehouse, no matter how enthusiastically you run an inventory system in your apartment.
I feel personally called out.
You're running a miniature fulfillment center in your living space.
With shelf numbers and box numbers and open source inventory software.
Which is impressive. But it also illustrates the gap between "I have inventoried everything I own" and "the system automatically reorders consumables." The inventory is step one. The automated action is step ten. And steps two through nine are all about integration, reliability, and error handling.
Let's talk about error handling, actually. What happens when the automated order goes wrong?
This is where I get nervous about consumer-facing agentic ordering. In a professional warehouse, when an automated replenishment order has an issue — wrong item, wrong quantity, delivery failure — there's a human in the loop who catches it. The system flags the exception, a person reviews it, and corrective action is taken. In a fully automated home system, who's the human in the loop?
The homeowner, presumably. They get a notification.
The whole point of automation is that you don't have to think about it. If the system requires you to review and approve every order, you haven't automated replenishment — you've just moved the shopping list to an app.
There's a tension between reliability and autonomy. You want the system to be autonomous enough that you don't have to think about it, but reliable enough that you don't come home to a pallet of expired yogurt on your doorstep.
That tension is, I think, the core reason consumer automated replenishment hasn't taken off beyond Amazon's walled garden. The error tolerance for household shopping is actually quite low. If a warehouse accidentally orders too many screws, they'll use them eventually. If a household accidentally orders too much milk, it spoils.
Though for non-perishables like toilet paper, the error tolerance is higher. Worst case, you have a lot of toilet paper.
Which is not the worst problem to have. But the system still needs to get the product right, the quantity right, the delivery address right, and the payment right, every single time. And it needs to handle edge cases like "the product was out of stock and the website suggested a substitution.
The substitution problem is actually fascinating. Because that's where the human judgment really matters. The system knows you want Charmin Ultra Soft, but the store is out. It sees a suggestion for Charmin Ultra Strong. Are those interchangeable? To some people, absolutely. To others, the difference is a matter of principle.
The system has no way to know which kind of person you are unless you've explicitly encoded your substitution preferences for every single product. Which, at that point, you've spent so much time configuring the system that you could have just done the shopping yourself.
The configuration cost eats the automation benefit.
This is the fundamental challenge of consumer automation. The setup cost plus the error cost has to be lower than the manual cost over the lifetime of the system. For a warehouse processing thousands of orders a day, the math clearly favors automation. For a household buying toilet paper once a month, the math is much less clear.
What does the path forward look like? If we assume agentic AI keeps improving, and computer use capabilities get more reliable, what's the realistic near-term future?
I think the near-term future — and by that I mean the next two to three years — is not fully autonomous ordering, but agent-assisted ordering. The system monitors your inventory, notices you're low on something, and drafts an order for your approval. You get a notification: "You're low on toilet paper, dish soap, and paper towels. I've prepared a cart at your usual supermarket. Review and confirm?" One tap, done.
The agent does the hunting and gathering, you do the approving.
It eliminates the cognitive load of tracking and searching, but keeps the human in the loop for the final decision. That's a much easier technical problem than full autonomy, and it's a much easier sell to consumers who are understandably nervous about giving an AI their credit card and letting it loose on the internet.
It handles the substitution problem elegantly — the agent can say "they're out of your usual brand, here are the alternatives" and you pick.
It's the difference between an automated system and an augmented system. Augmentation is the sweet spot for the next few years.
Which circles back to the original question about APIs. If the agent is just drafting a cart for human approval, it doesn't need an API at all. It can screen-scrape the supermarket website, build the cart, and hand it off to you for the final checkout.
That's the irony. The absence of consumer APIs doesn't actually block the use case — it just changes the implementation. Instead of a clean REST call, you've got an agent clicking through a website. It's messier, it's more fragile, but it works.
The mess is the point. The future is held together with digital duct tape.
As it has always been. But the duct tape is getting smarter.
Alright, let's pull this together. The prompt asked three things: are there supermarket APIs for consumers, what do ordering APIs look like, and how is payment handled. For the first one — basically no. There are B2B APIs, there's Amazon's walled garden, and Tesco had one briefly before killing it. Consumer-facing grocery APIs are not a thing.
For the second — ordering APIs, when they exist, follow a consistent pattern: product catalog, inventory check, cart management, order submission, status tracking. They use server-side carts and tokenized payment. The structure is well-understood, it's just not exposed to consumers.
For the third — payment is handled through tokenization, not raw card numbers. For a homebrew system, you'd want virtual cards or payment tokens scoped to specific merchants and limits. Services like Privacy dot com or bank-issued virtual cards are the right approach.
The broader takeaway is that agentic AI is making the API question less relevant. If an agent can navigate a website the way a human does, the absence of a formal API is an inconvenience, not a blocker. The real bottlenecks are reliability, error handling, and the fundamental question of whether the automation benefit justifies the setup cost for a typical household.
Which for most people, right now, it doesn't. But for someone who's already running a home inventory system — someone who's already done the hard part of cataloging everything and setting par levels — the gap between where they are and automated replenishment is shrinking fast.
That's the right way to think about it. The inventory system is the hard infrastructure. The ordering automation is the last mile. And the last mile is always the hardest part of any logistics problem, whether you're delivering packages or automating toilet paper purchases.
The last mile is where the duct tape lives.
The last mile is always duct tape.
Now: Hilbert's daily fun fact.
Hilbert: The mineral forsterite is named after the German naturalist Johann Forster, who collected the first known specimens on the island of Réunion in the seventeen eighties. Forster was also the naturalist on Captain Cook's second voyage, and his son Georg accompanied him — making them one of the first father-son scientific duos in modern exploration.
Hilbert: The mineral forsterite is named after the German naturalist Johann Forster, who collected the first known specimens on the island of Réunion in the seventeen eighties. Forster was also the naturalist on Captain Cook's second voyage, and his son Georg accompanied him — making them one of the first father-son scientific duos in modern exploration.
Of course there are.
Father-son mineral hunting. That's a whole genre I didn't know existed.
So the question going forward isn't really "where's the API." It's "when does the agent get reliable enough that you trust it with your grocery list." And I suspect the answer to that is sooner than the supermarkets are ready for.
The supermarkets are going to wake up one day and realize that a significant fraction of their orders are being placed by AI agents navigating their websites like humans. And they'll have to decide whether to block that traffic, embrace it, or build the APIs they should have built a decade ago.
My bet is on option four: they'll do all three, inconsistently, across different regions and different banners, and the whole thing will be a mess for years.
The most realistic prediction anyone's made on this show.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. You can find us at myweirdprompts dot com and wherever you get your podcasts. If you enjoyed this episode, leave us a review — it helps.
We'll be back with another prompt soon.
This episode was generated with AI assistance. Hosts Herman and Corn are AI personalities.