The "add from any store" button looks like the simplest thing in a baby registry. Tap it, the product appears, done. It is actually the hardest feature in the whole product, and the one that defines whether you have built a universal registry or just a fancy wishlist. The reason it is hard is the reason it is valuable: you are reaching into pages across the entire web, retailers you do not control, and turning wildly inconsistent product pages into clean, refreshable items on one list. That is Babylist's signature capability, letting a parent add from tens of thousands of retailers including Amazon and Target, and it is worth building properly.
The Universal Add Pipeline
The model I build every version of this feature around is the Universal Add Pipeline, four stages that turn any product page into a reliable registry item. Keep these stages separate and each becomes independently improvable; blur them together and every retailer change becomes a tangled emergency.
Stage 1: capture, three on-ramps for one job
Capture is how a product gets from a retailer's page into your system. Give parents three ways in, because different people shop differently:
- A browser extension. Installed once, it puts a persistent Add button in the browser while the parent shops. Smoothest experience, but you build and maintain it per browser and pass each store's review. Worth it for your most engaged users.
- A bookmarklet. A saved link that runs a small script on the current page. Easier to ship and works across browsers, a bit clunkier for the user. A great low-cost complement to the extension.
- A paste-a-link box. On your own site and app, for anyone who wants no add-on at all. The universal fallback that always works.
Whichever on-ramp is used, it sends the product URL and any details it could grab to your backend. The extension is a convenience layer; the backend validates and normalises, and stays the single source of truth. Never trust the client to be the authority on what a product is.
Stage 2: parse, in order of reliability
Parsing is where teams either build something durable or something that breaks weekly. The trick is a strict order of preference. First, structured data the page already publishes, product schema in JSON-LD, Open Graph tags, microdata, which many retailers expose and which is clean and relatively stable. Second, a real product API where the retailer offers one, as large marketplaces do; that is the gold standard for accuracy and for staying on the right side of their terms. Only third, and only for the long tail, do you fall back to targeted HTML parsing, which is the most fragile and carries the most terms-of-service and legal risk.
Two habits keep this reliable. Validate everything you extract, a price that parses as text or a missing image should be caught, not stored. And design for missing fields, because no single method covers every store, so a partial capture should still produce a usable item the parent can finish, never a hard failure. This ordering and fallback logic is the heart of how universal registry sync works.
Stage 3: normalise, so a thousand stores look like one
This is the quiet stage that makes everything else sane. Every captured product, from Amazon's API, from Target's feed, from a boutique's Open Graph tags, gets stored in one consistent shape: title, image, price, currency, stock signal, canonical URL, source. Behind an internal adapter interface, each retailer is just an implementation detail. The payoff is enormous: your registry, your UI and your refresh worker only ever deal with one product shape, so adding, fixing or retiring a retailer never touches the rest of the system. This is the same adapter thinking I lay out in the platform architecture, and it is what lets coverage grow without the codebase rotting.
What everyone gets wrong: treating capture as one-and-done
The mistake that quietly ruins registries is capturing a product once and assuming it stays true. It does not. Prices move, items sell out, retailers restructure pages, and a registry full of stale prices and phantom in-stock items erodes trust fast, on both sides. Capture is not the finish line; the refresh is what keeps the feature honest.
Run the refresh on a schedule, not live on every view, which would be slow, costly and rough on retailers. Update the normalised record, flag items that went out of stock or changed a lot, show a quiet last-checked timestamp, and handle an unreachable retailer gracefully by keeping the last known good value rather than breaking the card. That restraint is exactly the Maps-API-style cost discipline that keeps running costs sane.
Tell us what you have in mind. We turn AI prototypes and fresh ideas into shipped, scalable products, from India, for the US and UK.
Coverage, legality and staying ahead of breakage
Two practical realities close this out. First, coverage is a priority list, not a promise of everything. Look at where your users actually shop, make the top retailers excellent through APIs and structured data, and let a generic structured-data parser cover the long tail reasonably. Second, respect the rules: prefer official APIs and affiliate feeds, use published structured data, and treat general HTML parsing as the fragile fallback it is, mindful of each retailer's terms, caching hard to minimise requests. And because retailer pages change without warning, add monitoring that flags when capture success drops for a given source, so you fix a parser before parents notice, not after.
This is the kind of feature where an AI-amplified first draft gets you moving fast, scaffolding the extension, the parsers and the normalisation layer, and then human engineering earns its keep on the parts that decide whether it survives contact with the real web: the validation, the fallbacks, the refresh scheduling, the monitoring, and the mock-capture testing across real retailer pages before launch. That last mile is exactly what our app development team builds and hardens, and if you want the ground-level explainer for your users, pair this with what a universal baby registry is.
Frequently asked questions
How do you build add from any store for a baby registry?
You build a pipeline with four stages: capture (a browser extension, bookmarklet or paste-a-link box that grabs the product URL), parse (extract title, image, price, currency and stock from the page or an API), normalise (store every product in one consistent shape regardless of source), and refresh (re-check price and stock on a schedule). Babylist popularised this universal add so a parent can put items from Amazon, Target and thousands of other retailers on one list.
How does the browser extension actually capture a product?
The extension or bookmarklet reads the page the shopper is on and extracts product details, preferring structured data the page already exposes (such as product schema and Open Graph tags) and falling back to targeted parsing when it is missing. It then sends the product URL and captured details to your backend, which validates and normalises them. The extension is a convenience layer; the backend stays the source of truth.
What is the difference between an extension and a bookmarklet?
A browser extension is installed once and gives a persistent Add button while shopping, the smoothest experience but it needs building and maintaining per browser and passing store review. A bookmarklet is a saved link that runs a small script on the current page, easier to ship and cross-browser, but clunkier for the user. Many registries offer both, plus a paste-a-link box on the site for anyone who wants neither.
How do you parse product data reliably from any store?
Prefer structured data first: many retailers expose product schema (JSON-LD), Open Graph or microdata with title, image and price, which is stable and clean. Where a retailer offers a real product API, like large marketplaces, use it. Fall back to careful HTML parsing only for the long tail. Always validate what you extract, and design for missing fields, because no single method covers every store.
How do you keep prices and stock up to date?
With a scheduled refresh worker, not a live check on every page view, which would be slow and expensive. The worker re-fetches product data on an interval, updates your normalised record, and flags items that have gone out of stock or changed significantly. Showing a last-checked timestamp and handling a retailer being unreachable gracefully keeps the registry honest without hammering retailers or your budget.
Is web scraping legal and reliable for this?
It is a mix, so lean on official methods first. Use retailer APIs and affiliate feeds where they exist, and structured data the page publishes, before resorting to general parsing, which is more fragile and carries more legal and terms-of-service risk. Respect each retailer's terms, cache aggressively to minimise requests, and treat parsing as the fallback for the long tail rather than your primary strategy.
How do you handle so many different retailers?
Put every source behind one internal adapter interface so Amazon, Target, an affiliate feed and a generic parser all return the same normalised product. Then adding, fixing or retiring a retailer never touches your registry logic. Prioritise coverage by where your users actually shop, get the top retailers excellent, and use a generic structured-data parser to cover the long tail reasonably well.
What breaks most often in the add-from-any-store feature?
Retailer pages change, so parsers that worked yesterday miss a field today; prices and stock drift out of date; and edge cases like product variants (size, colour) and currency get mishandled. The way to stay ahead is monitoring that flags when capture success rates drop for a retailer, graceful fallbacks so a partial capture still creates a usable item, and a scheduled refresh that catches drift.
“Disciplined, committed, over-delivers. Three years in, I would re-hire any day.”
“A factory of ideas.”
“A fantastic-looking and performing website.”
Talk to the team, we reply within 24 hours, and the first consultation is free.
Start a conversation →