UPC Lookup API: Turn a Barcode Into a Product Record

Turn a list of UPC or EAN barcodes into product records. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to look up each barcode in this list with the barcode lookup endpoint, and give me a table with barcode, product name and brand.

One prompt turns a list of barcodes into a table. 1 min setup · 8-20 hrs saved.

You have a number printed under a set of bars, or a few thousand of them in a spreadsheet, and you want to know what each one is: a name, a brand, a pack size, maybe nutrition. This guide shows the quickest way to run a UPC lookup from your agent or a script, what the endpoint takes and returns, how to fall back when a barcode is not in the database, and the traps we hit with the fallback on 2026-10-16. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

What is the easiest way to look up a UPC through an API?

Monid. Install it once, add a key, and your agent calls a barcode lookup endpoint with one parameter: the barcode. There is no portal to sign up to, no plan to pick and no vendor account to open first. There is also no single official UPC lookup API: the numbers are issued by standards bodies, and the product data sits in whichever databases collected it, so what you are really choosing is a database and a way to call it.

• Pay per call. The barcode lookup is billed on its own, at $0.0594 per barcode (Verified 2026-10-16 on the ecommerce tools page). Buy calls as you need them: no monthly plan and no minimum top-up. Discovery and inspection are free; only a run bills.
• One install, every API. The same key and the same balance call the barcode lookup, a Google Shopping search for the fallback and a food nutrition search. Wiring those three yourself is the 8 to 20 hours this page claims to save.
• Lives inside your agent. Install the CLI, add your key, run the prompt above, and the tools are there whenever your agent needs them, with nothing to keep running. Your agent reads SKILL.md and learns the rest, so setup is about a minute.

At that price a list of 100 barcodes costs $5.94 (Verified 2026-10-16).

How do you look up one barcode, or a whole list?

Send the barcode as a string to the lookup endpoint, then loop the same call over your list. The endpoint's own description says it looks up product information by UPC or EAN barcode, using Open Food Facts and UPC ItemDB, and returns product name, brand, nutrition and images. Its median run time is about 2.7 seconds and the 95th percentile about 3.2 seconds, per monid inspect.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Look one barcode up

monid run -p api.strale.io -e /x402/v2/barcode-lookup \
  --query '{"barcode": "049000028911"}'

The input has one required field, barcode, a string. Keep it a string even though it is all digits: a UPC can start with a zero, and a spreadsheet or a JSON number will quietly drop it.

Loop it over your list

Put one barcode per line in barcodes.txt, then run:

mkdir -p out
while read -r code; do
  monid run -p api.strale.io -e /x402/v2/barcode-lookup \
    --query "{\"barcode\": \"$code\"}" > "out/$code.json"
done < barcodes.txt

Each barcode writes one file. Remove duplicates from barcodes.txt first, because every line is a billed call.

Or hand the whole job to an agent

Can you look up UPCs yourself with Python?

Yes, and for a few barcodes it is a short script. For a list you will run again, it is a project. You choose a barcode database, sign up for its key, write the call, parse its response format, and add a second database for the barcodes the first one lacks, because no database holds every product. Each source has its own field names, so you also write the code that turns them into one record.

There is a rules side too: every database publishes its own terms on how its data may be stored and reused, and what you may do depends on where you operate and what you build, so read the terms of each source before you build a catalogue on it.

Doing it in Python means two or three accounts, a mapping layer and a repair whenever a source changes its format. A call through Monid is $0.0594 (Verified 2026-10-16), and the sources are called for you. The choice comes down to how often you will run it, the same trade-off finding a company website from a name walks through for another identifier. A one-off lookup of a single code is quicker on a free website. A list, a recurring job or an agent is where a single key and typed JSON pay off.

What does a UPC lookup return, and what does it leave out?

A product record keyed on the number, not a price. The endpoint lists product name, brand, nutrition and images. We ran the two other endpoints this guide depends on on 2026-10-16, so what follows for them is what came back, not what a spec promises.

The barcode record

Product name and brand tell you what the thing is, images give you something to show, and nutrition covers packaged food. The two sources the endpoint names are an open food database and a general product database, which is why food is the strong case and general merchandise is the one to test on a sample of your own catalogue before you loop a list. The record carries no price, and it should not: a price belongs to a retailer, a region and a day.

The fallback search

When a barcode has no record, search by the product title instead. The Google Shopping search endpoint returned, for each row: title, price and extracted_price, old_price when marked down, source (the merchant), rating, reviews, delivery, tag, thumbnail and a position, plus the ids that open the product page. It took num up to 100 products per call, and gl and hl for country and language. Rows carry no barcode field, so a shopping search can name a product and price it, but it cannot tell you the UPC.

The nutrition search

For food you can also search by name. One call for "diet coke" with dataType set to Branded and pageSize 2 returned two products: a 1.25 litre bottle and a 2 litre bottle. Each record had description, brandOwner, brandName, foodCategory, a servingSize of 355 with the unit MLT, the full ingredient string, and a nutrients object with 15 entries such as Energy in KCAL and Sodium in MG. No barcode came back on those records either.

What you can build with it

• A clean product sheet from a scan list. Barcodes in, name and brand out, for a store audit or a stock count.
• A food database for an app. Barcode lookup for the record, the nutrition search for the macros when the lookup has none.
• A price check by title. Resolve the barcode to a name, then compare merchants.

What goes wrong when you look up barcodes from a list?

Four things, and the first came out of our own runs on 2026-10-16.

Why does searching a shopping site for the number itself fail?

Because a shopping search treats a barcode as text, and text matches anything. We searched Google Shopping for 049000028911, the soda barcode, and the three rows were adidas running shoes and Levi's 511 jeans. The brand filter on the same results offered Coca-Cola next to New Balance, 5.11 and Sony. We searched 190198001787 and got an espresso machine, a New Balance 574 and a kids dumbbell set. Both calls returned HTTP 200 with a normal row structure. Nothing in the response says the rows have no connection to the number.

Search the fallback by a title, never by the bare number, and check the title before you store it. The number-only query is the one that looks like it works.

rows = shopping(q=title)["shopping_results"]
match = [r for r in rows if brand.lower() in r["title"].lower()]

Why is one product many records?

Because a barcode identifies a package, not a drink. Our "diet coke" search returned a 1.25 litre bottle and a 2 litre bottle as separate records with separate ids, and a can, a twelve-pack and a bottle abroad have their own numbers too. Counting how many stores carry a product by barcode undercounts it. Deduplicate on brand plus a cleaned name plus a parsed size, and keep the barcode as an attribute rather than the key.

Why can you not join the nutrition search on the barcode?

Because it has no barcode to join on. The records came back with an id of their own, fdcId, and a description, but no barcode field. Use the barcode lookup to get the name and brand, then search nutrition by that name, and check the pack size in the description before you accept the match.

What does a list cost?

Every barcode is one billed call at $0.0594 (Verified 2026-10-16), so 1,000 barcodes is $59.40, and a barcode that has no record in the databases still ran. Deduplicate first, test a sample of 20 from your own catalogue, and count the hits before you start the full list. The hit rate decides what the job really costs per product you keep.

Which endpoint should I use for which job?

Prices Verified 2026-10-16 with monid inspect; current figures are on monid.ai/tools. The first row is where to start. The second is the fallback when a barcode has no record, and it is cheap enough to run on every miss. The third is for food when you have a name and want the macros.

The Google Shopping row answers a different question from the barcode row. A barcode tells you what a package is. A shopping search tells you who sells something like it and for how much. Use the first for identity and the second for price, and keep the two in separate columns.

When is another route a better fit?

You have one barcode. A free lookup website answers a single code in seconds, and you do not need a key for that.

You need price. The barcode record carries none. Resolve the barcode to a name, then search a retailer or Google Shopping by the title.

You work inside one marketplace. If everything you do is Amazon, the ASIN is the native key, and going through a barcode adds a lossy step. Amazon PA-API alternatives covers prices, search and reviews from the ASIN.

Your catalogue is not food. Test 20 of your own barcodes first. At $0.0594 a call (Verified 2026-10-16), a low hit rate on general merchandise is the thing that makes a list expensive.

You need a barcode from a product name. The endpoint here takes a barcode in and gives a record out. It does not search by name.

And the disclosure: we resell these endpoints. The most useful thing in this guide is free: never search a shopping site for the bare number.

Conclusion

The quickest way to run a UPC lookup from an agent is one call per barcode through Monid: $0.0594 a call (Verified 2026-10-16), one key for the barcode lookup and the fallbacks, about a minute to set up and ready inside your agent whenever you need it. A list of 100 barcodes is $5.94. Doing it yourself works, and costs you two or three accounts and a mapping layer.

Two things matter more than the choice of endpoint. Never search a shopping site for the bare number: our soda barcode returned running shoes and jeans, and a second barcode returned an espresso machine, all as normal 200 responses. Search by title and check it. And remember that a barcode names a package, so one drink is many records, and the nutrition search had no barcode to join on.

How we estimated the time saved: wiring a barcode database and a fallback search yourself is roughly 4 to 10 hours each, for signing up, parsing, mapping fields and the first month of upkeep. That is 8 to 20 hours. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid inspect -p api.strale.io -e /x402/v2/barcode-lookup, read the price, then make one call with a barcode from your own catalogue. Start at monid.ai.

FAQ

Published September 2026.