Where does broken barcode data actually hurt?
A wrong or inconsistent GTIN looks harmless on its own; the damage shows up in a rejected listing, a wrong product match and a return. Below are the concrete situations we solve — and we have written down the ones we do not.
The marketplace listing is rejected
The situation. You upload the product, the marketplace says “invalid barcode” but will not say which one. Searching thousands of rows one by one takes days.
What we do. Run the list through batch validation; which row is invalid, why, and what the check digit should have been all arrive next to you in a CSV.
- Rows with a wrong check digit are flagged with the correct digit
- Rows with the wrong length (7, 9, 11 digits) are separated out
- Rows with an invalid format or length are listed separately
Formats differ between systems
The situation. The same number may arrive with spaces, hyphens, or in UPC/EAN form.
What we do. We clean the input safely, identify its type, and normalize it to GTIN-14.
- The check digit is validated separately
- The expected digit appears beside an invalid row
- Product data comes only from an authorized source
Catalogue migration / merger
The situation. You are merging two systems. The same product sits there in two different forms: one a 12-digit UPC, the other a 13-digit EAN.
What we do. We normalise everything to its GTIN-14 equivalent, so matching happens on a single format.
- A UPC-A is padded with a zero to 13 digits and its GTIN-14 equivalent is produced
- Spaces, dashes and invisible characters are cleaned out
- Two records of the same number are merged during upload
ERP / PIM integration
The situation. You want to check the barcode while a product record is being created, but you do not want to write separate code for every system.
What we do. A single REST call is enough. You create the key and you decide its scope and lifetime.
- GET /api/v1/gtins/{gtin} — a single number
- POST /api/v1/batches — a list or a CSV
- A key’s lifetime and scope can be restricted from the panel
Here is the difference: we write down why the row was rejected and what it should have been right next to it. Instead of hunting one by one, you open the file and fix it.
The difference from doing it by hand
| Task | By hand | GTIN Data Hub |
|---|---|---|
| A list of 10,000 rows | An Excel formula, with a wide margin for error | One file upload, result as CSV |
| Finding the invalid row | Seeing the rejection and going back | The reason and the correct value right beside it |
| Unifying formats | Resolving UPC/EAN differences by hand | Automatic GTIN-14 normalization |
| UPC and EAN getting mixed up | Telling them apart by eye | Everything is normalised to GTIN-14 |
| Connecting it to your system | Separate code for every system | A single REST call |
Who uses it
Marketplace seller
Batch validation before listing; seeing in one file why products were rejected.
Brand and manufacturer
Auditing the consistency of your own numbers, keeping the lists that go out to dealers clean.
Wholesaler and distributor
Bringing lists from different suppliers into one format, seeing conflicting records.
Software team
Adding barcode validation to an ERP, PIM or e-commerce stack over the API.
Data team
Normalising numbers during a catalogue migration and cleaning them before matching.
Audit / quality
Following which record changed when, and who queried it, from the audit log.
What we do not solve
Knowing it up front beats being disappointed later.
We do not give price, units sold, stock or market share. That data is not in the system at all.
We do not supply the product name and image. They come only from the catalogue you upload — Data coverage.
Try it with your own number
No sign-up needed. Type a barcode into the box on the home page; the format and check digit come back instantly.
Try it on the home page