Zé do Precinho is LNData’s Brazilian retail price intelligence platform. It collects the public prices of supermarkets and pharmacies daily — store by store, not chain by chain —, normalizes everything into a single format, keeps the history and delivers the result through two doors: a paid REST API, for those integrating into their own BI or ERP, and a web application, for those who want to use it by hand.
Retail prices are public, but fragmented, regional and ephemeral. Each chain publishes on its own site, with internal naming and internal codes. The same product from the same chain costs different amounts in each city — and this is measured: between Criciúma and Florianópolis, on the same day, up to 41.9% of prices diverge. And yesterday’s price no longer exists anywhere. Whoever needs this data builds their own scraper: fragile, expensive to maintain and silently broken whenever the site changes.
We built Zé do Precinho, an end-to-end data platform: an automatic daily collection engine, real regionalization by postal code, verifiable product identity by barcode, an analytical warehouse with the full history and a commercial REST API with billing coupled to consumption. Alongside it comes a complete web application — search, store-by-store comparison, history chart, shopping lists with cart optimization and price alerts with push notification.
The data arrives normalized, historical and auditable — with no scraper to maintain. Today the system collects six chains from six distinct economic groups every morning, answers for 19 cities and tracks 66,599 products identified by barcode. From the first commit to production with real payment: 17 days.
Three independent axes — the retail segment, the e-commerce platform and the retailer — support the entire collection layer. Each adapter emits the same canonical contract; the rest of the system never knows the origin. The practical consequence: adding a retailer that runs on an already supported platform costs one configuration entry and zero code.
An end-to-end flow that turns scattered public catalogs into queryable data: collect → normalize → identify → historize → serve → bill.
Collection runs automatically every morning, one run per retailer, with isolation per unit: a category that fails is accounted for and the others carry on — one broken category does not cost the whole catalog.
The system distinguishes the collected market from the served market — the one where the retailer itself declares it delivers from a store already covered. It is not an approximation from a neighbouring city: it is the same seller and the same region, and the API response states which market each row answers for.
Comparison only groups offers by provably global codes — a barcode with a valid checksum, or a manufacturer code when it is strong enough. Without that, the comparator would show a price difference between different products.
Each collection inserts new rows and never updates old ones. Re-running a collection is safe by construction, and the complete time series stays available to query — it is what nobody else kept.
Store comparison, current price, historical series and text search, with multi-value scope filters by state, city, retailer and store. The discovery vocabulary is exactly what the filters accept, with no translation in between.
Search, store-by-store comparison with a history chart, shopping lists with cart optimization, price alerts with push notification, credit purchase and interactive API documentation behind login.
What technically sets the project apart is not scraping sites — it is everything that exists around the data. Every relevant decision was made with measurement, not intuition.
Platform catalog APIs have a pagination ceiling, and above it the rest of the catalog becomes unreachable. The solution is an adaptive descent through the category tree, with price-range slicing on large leaves — coverage rose from 86.6% to 98.7%, recovering 11,591 products.
In a test over 10,158 barcodes shared across three chains, no platform "reference" field matched — it is the store’s internal code. And 42.2% of brand-and-model keys merged distinct products. Using them would produce wrong comparisons, which is worse than no comparison because it looks right.
Every run goes through automatic checks compared with the median of that retailer’s last seven days — because each source has its own normal, and a fixed threshold would always alert on one and never on the other. The verdict has three states: a collection that ends 30% smaller is neither success nor failure.
A commercial API does not end at the endpoint: it has to bill with transactional consistency, defend itself against abuse and speak up on its own when the day’s data did not arrive.
Credits live in batches with expiry dates and consumption debits the batch that expires first, crossing batches when needed — before that, a client with a distributed balance was told "no credits" on an operation the balance covered.
An atomic rate control protects both the source and the cost, and repeating the same query inside the cache window returns the result without debiting. Sustained throughput is the same for the API key and the site session, on purpose: a higher ceiling on the interface would be the back door.
Across 82,582 pairs of consecutive observations, 86.3% of prices do not change — and when they fall, the median drop is 19.3%. The signal is rare and large, so the thresholds are fixed presets: a free-form percentage would give false precision. And the notice carries the reference date, because "down 30%" without saying since when is a claim without a size.
A daily email summary says, in three states, whether the day went well. It exists because three failures were indistinguishable: the collector ran and found zero, the run died before writing, or it never started — none leaves a trace in the data, precisely because the defect is the absence of data.
Whoever needs shelf prices stops maintaining their own scraper: the data arrives normalized, with history and with verifiable product identity.
Regionalization is real and measured — 18% to 42% of prices diverge between cities of the same chain, a difference a chain-level comparator simply cannot see.
Billing is coupled to consumption with transactional consistency, in production with real payment via Pix, bank slip and card.
Source curation rejects candidates with numbers in hand — one pharmacy was refused for being the same company as another already collected, and another for bringing a single comparable product.
If your company tracks shelf prices, builds price indices or feeds a product with retail data, Zé do Precinho delivers it over an API. Explore the platform or talk to LNData.
