A barcode scanning app for books turns a back cover into a catalogue record.
The barcode on the back of a book is not a random number. It is the ISBN, printed as an EAN-13, and that is why a barcode scanning app for books can be so fast. One scan gives you a key that a public catalogue will trade for a title, an author, a publisher and a cover image. The rest of the work is deciding what you want to keep. Shelving a few hundred books has the same shape as the other home inventory apps, with one advantage: books arrive pre-labelled.
This page covers what the scanner actually reads, which free ISBN lookup service you can call without an API key, what a record has to hold once the lookup fills it in, and what happens when you are standing in a basement with no signal.
Check an ISBN yourselfThe short version
The scan is the fast part, the record is where the decisions are.
Almost every book printed in the last fifty years carries an ISBN, and since 2007 that ISBN is thirteen digits long and prints as an EAN-13 barcode. A phone camera reads it in under a second. A free public API turns it into a title and an author. Neither of those steps is the hard part.
The hard part is that your list is not a list of books. It is a list of copies. Two paperbacks of the same novel are two rows, the same novel in hardback is a different ISBN entirely, and the one you lent to your brother in March needs somewhere to say so. Tools that model books rather than copies fall over in the first week.
What the barcode on the back actually says
The long barcode on a back cover encodes the ISBN. Since 1 January 2007 an ISBN is always thirteen digits, built from five parts: a prefix element that can currently only be 978 or 979, a registration group for the country or language area, a registrant element for the publisher, a publication element for the title, and a check digit. The check digit is the final single digit and it mathematically validates the rest of the number, using a modulus 10 system.
That check digit is worth using. An ISBN scanner app that validates the number before it calls anything catches a misread on the device, for free, with no network. Multiply the first twelve digits alternately by one and three, add them up, and the check digit is whatever carries the total to the next multiple of ten. If it does not match, you misread the code. Scan again rather than spending a lookup on a number that was never real.
The other thing to settle early is that an ISBN identifies a product form, not a story. The standard is explicit that each different product form, for example paperback, EPUB or PDF, should be identified separately. So the hardback and the paperback of the same title carry different numbers and come back as different records. If your catalogue is meant to answer the question do I already own this, decide now whether you are tracking editions or titles, because the barcode only ever tells you the first one.
International ISBN Agency, what an ISBN is
Try it
Catch a misread before you spend a lookup
Type the thirteen digits from a back cover. The last one is a check digit, so a bad scan is catchable on the phone, with no network.
Valid ISBN 13
First twelve digits multiplied alternately by one and three, summed, then carried up to the next multiple of ten.
Yes, there is a free ISBN lookup API with no key
Open Library runs a public API that needs no key and no registration at all. Ask for openlibrary.org/isbn/9780140328721.json and you get back the title, publisher, publication date, author keys and cover ids for that edition. The search endpoint takes the same number as a query and lets you name the fields you want, which keeps the response small. Cover images come from the same place, by ISBN, in small, medium or large, again with no key.
The terms are worth reading before you lean on it. The default rate limit is one request per second, and three per second if you identify your application with a User-Agent header carrying the app name and a contact email. Open Library states plainly that its APIs are not intended to serve as a bulk data backend or high-traffic commercial infrastructure, and that violations may result in aggressive rate limiting or blocking. For someone cataloguing a few thousand books that is generous. For a shop scanning stock all day it is a conversation to have first.
The honest limitation is coverage rather than cost. Mainstream trade books resolve almost every time. Self-published titles, academic monographs, older foreign-language editions and anything printed before the system was in general use often do not. So build the manual entry form on day one, and make it the same form the lookup fills in rather than a separate path, because the rows that need typing are exactly the rows that matter most to the person typing.
A book cataloguing app stores copies, not books
Once the lookup has filled in title, author, publisher and year, the fields that matter are the ones no API can give you. Where the copy sits: room, shelf, box number. Who has it right now. What condition it is in. What you paid. Whether it is the signed one. A book cataloguing app that only mirrors the public record is a search engine you already had.
Model it as two things even if you never say the word database out loud. One record per edition, keyed on the ISBN, holding the facts the lookup returned. One record per copy, pointing at an edition, holding everything true of your physical object. Scan the same ISBN twice and you get a second copy, not a duplicate warning, which is exactly right when you own two. Lending, loss and condition all hang off the copy, and none of them belong on the edition.
That split is also what separates a home library app from stock control. Once you need counts, reorder points and a location that changes daily, you are building an inventory barcode scanning app instead, and the fields pull in a different direction. And when the things you want to track carry no printed code, a tag you attach yourself and read with an rfid scanner app does something a camera cannot: it reads without line of sight, so a whole shelf answers at once.
Shelves are usually where the signal is not
Cataloguing happens in basements, storerooms, church halls and the back of a garage. This is the failure nobody plans for: the camera works, the lookup does not, and an afternoon of four hundred scans is lost because every row needed a network round trip before it could be saved.
The fix is to split the two steps apart. A scan writes a row immediately containing nothing but the thirteen digits, a timestamp and a local id. Enrichment is a separate job that runs later against whatever rows are still bare. The person scanning never waits for anything, and a queue of nine hundred unenriched ISBNs is a perfectly reasonable state for the app to sit in overnight.
That design gives you a correctness check for free. If the enrichment pass finds a valid ISBN that no catalogue recognises, the row is either a genuinely obscure edition or a fat-fingered manual entry, and either way it belongs in a short review list rather than quietly on the shelf. The mechanics of cataloguing without a connection, queue design, conflict handling and what to reconcile when the signal comes back, are their own subject.
What each way of cataloguing actually gives you
| Option | Reads the ISBN | Fills in title and author | Fields you define | Works with no signal |
|---|---|---|---|---|
| Spreadsheet, typed by hand | No | No | Yes | Yes |
| Consumer book tracker app | Yes | Yes | No | partly |
| Web based cataloguing service | Yes | Yes | fixed set | No |
| Barcode app plus a shared sheet | Yes | codes only | Yes | No |
| A cataloguing app you build | Yes | via a free ISBN API | Yes | Yes |
Building one around your own shelves
Off the shelf book trackers are built around a shared social catalogue: ratings, reviews, want to read lists. That is a different product from a register of what is physically in a building. The moment you need a field that is yours, a shelf code, a donor name, a classroom, a date a copy has to go back to the diocese, you are working against the tool rather than with it. The same goes for the workflow: a school library wants one volunteer scanning a trolley, not thirty people rating books.
Newly is an AI app builder. You describe the app in plain English, including the fields your catalogue actually needs, and it writes a real React Native and Expo project you own, running it on a cloud simulator while it builds. Plans start at $25 a month and there is no free plan. iOS builds ship through TestFlight with your own Apple Developer account, and Android goes to Google Play internal testing from the Deploy tab, or out as a standalone APK. It is not a library management system and it brings no catalogue of its own, so the ISBN lookup is still something you wire up.
Whatever you use, settle the copy versus edition question before the first scan. It is a ten minute decision at the start and a full re-import at the end.
Questions people ask about scanning books
Yes. Open Library publishes one. You can request an ISBN as JSON, and fetch cover images by ISBN, with no key and no registration. The default rate limit is one request per second, or three per second if you send a User-Agent header naming your application and a contact email. Open Library says the APIs are not intended as a bulk data backend or high-traffic commercial infrastructure, so heavy commercial use is worth asking about first. Google Books will also answer some volume queries without a key, but unkeyed requests can come back rate limited, so treat that one as a fallback.
Describe the shelf, not the software
Write down the fields your catalogue actually needs, including the ones no public record will ever hold, and build the scanning around them.
Start building