Adding Barcode Product Data to a Mobile App

The scan-to-card loop

The core of any barcode feature on mobile is a short loop: the camera reads a code, your code cleans and validates it, a product-data API resolves it, and the screen shows the result. Get that loop tight and the experience feels instant; a scan becomes a product card in well under a second.

1. Scan - the device camera or a hardware scanner reads the barcode value.
2. Clean and validate - strip stray characters and confirm the check digit locally before any network call.
3. Resolve - send the GTIN to the lookup endpoint and receive the product record.
4. Render - populate a product card, or fall back gracefully on a miss.

Validating on the device first, with the barcode validation tool logic, means a misread never becomes a wasted request. The generic version of this pipeline is covered in how to build a barcode scanner feature; here the focus is the mobile specifics.

Keep the token off the device

The single most important decision is where the API token lives, and the answer is never the app. A token shipped inside a mobile binary can be extracted from the package and used to drain your quota. Route every lookup through your own backend, which holds the token and forwards the call.

Phone  ->  Your backend (holds token)  ->  Barcodes.GG API
       scan GTIN            authenticated lookup

The proxy earns its keep in other ways too. It is the natural place to cache popular codes, enforce per-user rate limits, and rotate the token without shipping a new app build.

Cache, and handle misses

Two behaviors keep a mobile scanner fast and cheap. First, cache by GTIN. The same shoes get scanned repeatedly across a stockroom, and a local or backend cache means the second scan of a code is free and instant. Second, respect the response metadata: request_debited tells you when a call counted against quota, so you can surface usage and avoid surprises.

Handle the miss deliberately. A code that is not in the catalog returns a 404, not an empty product. On mobile that should become a clear not-found state that invites another scan, rather than a spinner that never resolves. A validated-but-unknown code is a genuine miss; a validation failure before the call is a rescan prompt.

A finished product card

A product card feels finished when it answers the three questions a user has at a glance: what is this, is it the right one, and what size. The lookup response carries exactly those fields.

Request only the fields the card renders by passing a comma-separated fields list rather than fields=*. Smaller payloads mean faster cards on a phone connection. The full field catalog is covered in what data a barcode lookup API returns.