Australia's supermarket pricing debate is easy to read as a consumer pricing story.
For digital teams, it is also a bot and API protection story.
The ACCC's final supermarket inquiry recommended that ALDI, Coles, and Woolworths publish prices on their websites. It also recommended that Coles and Woolworths make dynamic price APIs available for third-party comparison tools.
Then, on 18 May 2026, Guardian Australia reported on CW Scanner data about Coles and Woolworths promotion patterns. The detail that matters for digital teams is this: the report said CW Scanner's operator stated the service was not scraping, and instead used the supermarkets' website application programming interfaces.
That does not settle questions about permission, terms of use, supermarket approval, or the status of any specific API. It does make the practical problem clearer.
Price transparency increasingly depends on automated access to current data.
And automated access always needs a decision.
APIs do not remove the bot problem
It is tempting to treat an API as the clean alternative to scraping. Sometimes it is. A documented API can make access more predictable, auditable, and easier to govern than repeated extraction from product pages.
But an API is still an automation surface.
The same retailer or marketplace may need to support:
- public product pages;
- price, promotion, search, listing, catalogue, and inventory routes;
- browser-backed application calls;
- documented APIs and partner feeds;
- comparison tools and public-interest services;
- search engines, monitoring systems, and accessibility tooling;
- unknown collectors rebuilding price, inventory, availability, or ticketing datasets outside the intended access model.
Some of that traffic is useful. Some of it is commercially necessary. Some of it is abusive. Much of it will not identify itself honestly.
So the question is not "should bots be blocked?"
The question is: can you tell intended automated access from uncontrolled extraction?
The decision needs evidence
A blanket "block all automation" stance can break comparison services, partner integrations, search visibility, monitoring, accessibility tooling, and APIs that were built to be automated.
A blanket "allow everything" stance can expose pricing, product, inventory, account, checkout, ticketing, and API paths to extraction and abuse.
The useful middle ground is governed automation:
- publish the access you want to support;
- recognise the clients and behaviours you expect;
- validate API route, schema, method, authentication, and client context;
- detect traffic that no longer fits the intended use;
- keep decision logs so security, legal, product, and commercial teams can review what happened;
- respond proportionately with allow, log, rate-limit, challenge, block, or review decisions.
That is where bot protection becomes more than a yes-or-no control.
It becomes the system of evidence behind each access decision.
Where Peakhour fits
Scraping protection should identify repeated extraction across product, price, search, listing, catalogue, article, inventory, and availability routes. The goal is not to stop every non-human request. The goal is to separate expected access from collectors rebuilding data outside the site's control.
API bot protection applies the same discipline to automated API clients. APIs exist to be automated. The risk comes from unknown clients, unexpected route combinations, credential abuse, endpoint enumeration, excessive request volume, and business-logic abuse that generic perimeter controls cannot explain.
Bot management turns request evidence into a decision: allow trusted traffic, log expected automated access, rate-limit noisy collectors, challenge uncertain sessions, block confirmed abuse, or send edge cases to review.
Verified browser trust adds a useful signal when browser-backed journeys are being automated or replayed. Headers and cookies can be copied, proxy networks can rotate, and automation can mimic ordinary navigation. Peakhour can challenge the browser path, verify that the expected evidence came back, and attach that witness to the wider decision record.
That browser signal does not prove the user, device, or account is automatically trustworthy. It helps the risk engine decide what to do alongside route, proxy, device, behaviour, credential, and API context.
Why this matters beyond supermarkets
The ACCC's 2024 proceedings against Coles and Woolworths were about alleged false or misleading price statements, not supermarket price regulation, collusion, or anti-competitive conduct. The ACCC announced on 14 May 2026 that the Federal Court found Coles made false or misleading representations in 13 of 14 agreed sample "Down Down" tickets, with penalties and other orders still to be determined. For Woolworths, the separate "Prices Dropped" proceeding was awaiting judgment at publication.
Those legal details matter, but they are not the Peakhour point.
The Peakhour point is operational: whenever transparency, comparison, availability, or fairness depends on current digital data, organisations need a control plane that can support the access they intend and limit the extraction they do not.
That pattern shows up in retail, marketplaces, ticketing, travel, financial services, media, and any platform where public pages, browser-backed calls, and APIs expose commercially valuable data. It also shows up in adjacent problems like account abuse, checkout abuse, ticket scalping, product scraping, distorted analytics, and inventory harvesting.
The organisations that handle this well will not be the ones that treat every automated request as the same.
They will be the ones that know what access they intend to allow, what behaviour they intend to stop, and why.
