Gift Registry API: Build a Registry From Real Products
A registry is a list your app keeps. The products, prices and stock behind it come from an API. This guide shows what to store, what to fetch and how to keep a registry accurate, with a demo that builds one from real products.
A gift registry is a list of products that other people buy from. The list is yours to build, but everything on it comes from somewhere else: what the product is, what it costs, where it is sold and whether it is available today. A gift registry API is the part that answers those questions. It is also what many teams mean by a product list API, a way to attach real product data to a list your application keeps. This guide explains which parts of a registry the API handles, what to store and what to fetch, and lets you build a registry from real products. The demo below uses prices last pulled November 13, 2026.
What a gift registry API does, and what it does not
It helps to be exact about the split, because it decides what you build. The API does not hold registries. It does not know who the list belongs to, who has bought what or which guests have seen it. Your application keeps all of that. What the API supplies is the product side: it finds products, identifies them, and reports the price and stock in every store that sells them.
That split is also why the data should stay out of your registry table. A price saved when someone added an item is out of date by the time a guest opens the list. The reliable pattern is to store the barcode and fetch the rest when the registry is shown.
Build a registry from real products
The demo below is a small registry. Add products and each one shows the store with the lowest in-stock price, how many stores carry it and how far apart the in-stock prices are. Every figure comes from one real Price History API response for that product’s barcode. The page holds a rotating set of products that is rebuilt every night, and it offers four of them, a different four on most visits.
Notice what the registry row is made of. The product name and picture, the store, the price and the stock were all fetched. The only thing your database would hold for this row is the barcode, which is enough to ask the question again tomorrow.
The requests a registry makes
A working registry needs only a few kinds of request, and one of them does most of the work.
The same request works as an MCP tool, which matters if the registry sits behind an assistant that answers questions such as where a gift is cheapest. Our guide to barcode search covers the identifiers, and MCP or REST covers the two ways of connecting.
What to store, and what to fetch
Two habits follow. Keep the time you fetched a price and show it, so a reader knows how fresh it is. And do not store a price as a fact about the item. A short cache is fine, since the data behind the response changes over hours and not seconds, but the registry should always be able to ask again.
Handling sold-out items and price changes
A registry lives for months, and items change while it does. A product goes out of stock at one store and stays available at another, a price drops during a sale, a store stops listing it. If the registry remembers only one store, each of these becomes a dead end for a guest. Because the response lists every store, a registry can pick the best one that has the item in stock at the moment it is shown, and say so when the first choice has run out.
Our guide on handling out-of-stock and price-changed offers goes through the cases, and comparing regular price and final price explains how to show a discount that is real. Registries that also let people save items privately can build on the ideas in the Wishlist API guide.
What the November 13, 2026 pull shows
Sorting out which store to send a guest to only matters if the stores differ, so we looked. On November 13, 2026 we pulled every store that sells each of the six products in that day’s set. One of the six products with two or more stores in stock had a gap of at least ten percent between the cheapest and the most expensive store. Four of the six products had at least one store that did not have them in stock. For those items a registry that remembered a single store could have sent a guest to the wrong place.
Added together at each product’s lowest in-stock price, the set cost $1475.78. At each product’s highest in-stock price the same set cost $1497.96. The difference is what choosing the store is worth to a guest on that day.
This table is fixed to November 13, 2026. The demo above is rebuilt every night from a rotating set of products, so its figures will change. Treat the table as a record of one day. A handful of products is a small sample and not a measure of any market. Each figure is a store’s current price in US dollars, and the gap is the difference between the cheapest and the most expensive in-stock store, as a percentage of the cheapest.
Terms
Getting started in three steps
- ✓Every store that sells an item, in one request
- ✓Today’s price and stock, with the recent range
- ✓The same data as an MCP tool or a REST request
{
"target_type": "barcode",
"target_ids": [
"75536300504"
],
"currency": "USD",
"include_series": false,
"include_stats": true,
"include_product": true,
"per_page": 25
}