The aggregators never answer the upstream question

One thesis: the aggregator tier of barcode lookup APIs shares one structural silence — no per-attribute provenance and no license metadata — and an enrichment layer that cannot say where an attribute came from cannot say whether you may use it, which makes provenance the first checkbox on the RFP, not the last.

If you hold the standards-and-compliance line in a product org, you have probably evaluated this category: paste a UPC, get a product name, an image, a category, maybe nutrition. The demos are quick and the coverage numbers are large. This post is the diligence layer under the demo, stated factually and linked to each vendor's own published terms — respectful, because several of these services are genuinely good at what they actually are.

The field, as published

Say the honest things first. Nutritionix's lane quality is real: curated vertical data is a different product from a scrape, and it shows. EAN-DB publishes its method and prices plainly. Digit-Eyes has served its niche for a long time. None of what follows is an adoption claim about anyone — usage numbers belong to the vendors who have them.

The common pattern

Across the tier, three properties recur, each verifiable in the vendors' own documents:

• No per-attribute provenance. No response format in the tier tells you which source produced this field of this record. The record is a merged artifact; the lineage is gone at merge time.
• No license metadata. No response says what you may do with a value — display it, store it, redistribute it. The terms answer instead, globally, and the answer is restrictive: one service's API specification bars users from building "databases or otherwise creat[ing] permanent copies of such content"; another's terms require that on termination "you shall delete all Product Data previously provided to you (including any cached and backed up Product Data)"; a third forbids "resell, redistribute, or make publicly available."
• The upstream disclaimer. The same terms that claim IP over "Product Data" also concede its edges — one admits outright that "Some elements within Product Data… belong to third-party owners"; another describes its corpus as gathered "using cutting-edge data mining techniques." Mined, not licensed.

Assemble those three and you get the structural silence this post is named for. The vendor cannot tell you where an attribute came from; the vendor's own terms suggest the vendor is not certain either; and the rights they grant downstream are narrower than the uses an enrichment integration actually makes. The tier's problem is not data quality. It is that the foundation question — what are the upstream rights, per field — has no answer anywhere in the stack, and everything your product builds on top inherits that unanswered question. Why the licensed rails upstream force exactly this outcome is the licensing-wall post, clause by clause.

The question a compliance team asks

Your RFP checkbox is usually phrased as coverage: how many GTINs. Reframe it as demonstrability, which is the delta your seat actually owns: for any attribute in any response, can the vendor produce source, license, and freshness — in the response itself, machine-readable? That phrasing has two virtues. It is checkable in an afternoon against a sample of responses. And it cleanly separates the two products this category conflates: a big index of unattributed strings, and an answer layer your auditor can walk backwards.

Here is what the second product looks like, per attribute, in the response:

{ "attribute": "ingredients",
  "value": "whole grain oats, …",
  "source": { "id": "usda-fdc", "dataset_version": "FDC 2026-04", "digest": "sha256:…" },
  "license": "public-domain",
  "fetched_at": "2026-07-31T…" }

Every field a response carries names its source, its snapshot, its license class, and its age — the envelope post specifies the schema and the enforcement rule (a storage-scoped response cannot contain display-only attributes; the filter runs at assembly). Provenance of this kind cannot be bolted onto a merged corpus afterwards, because the lineage was destroyed when the corpus was merged. It has to be the architecture from the first row, which is why the segregated-source design exists.

What "we don't know" looks like here

One more contrast worth putting in the RFP: failure shape. An aggregator under coverage pressure returns something — a stale merge, a near-neighbor, a guess with a product image. This API returns the attribute or it doesn't: an attribute with no licensed source is absent, not invented, and a wholly unknown GTIN is an honest exit-code-1 verdict, not a fabricated record. For a compliance seat, absence you can trust is a feature; for an agent consuming the API, it is the difference between a filterable answer and a liability. Ask your shortlist what their API returns when it does not know — then get an API key, run your own GTINs through the enrichment tiers, and compare the answers attribute by attribute.

Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.

We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.