Listing a second-hand book should take seconds, not minutes. Yet on most marketplaces, sellers have to type out the title, paste in the author, hunt down a description, find a cover image and guess the right category. By the time they finish, the book is back on the shelf and the listing is half written. At ReReadz, we use a small constellation of Google APIs alongside open web standards to remove almost all of that friction. Here is how it works, and why we made the choices we did.
The problem we are solving
Sellers fall into two camps. Some have a single shelf they want to clear. Others have hundreds of books accumulated over decades. Both groups bounce off long forms. If listing the first book takes five minutes, the next nine never happen.
We wanted a flow where the seller could pick up a book, point a phone at the barcode, and have everything that does not depend on their judgement filled in for them. Their job is to set the condition and the price. Our job is everything else.
Step one: Google Books API for metadata
The Google Books API is the workhorse of our listing flow. Given an ISBN, it returns the canonical title, author, publisher, publication date, page count, language and a short description. For most books, the response also includes a thumbnail cover.
We do not take that data uncritically. The API can be inconsistent for older or specialist titles, so we run each response through a normalisation layer that:
- Strips marketing language out of descriptions and trims to a sensible length.
- Splits multi-author strings into structured arrays.
- Validates ISBNs and reconciles ISBN-10 with ISBN-13.
- Falls back to Open Library when Google does not have a record.
That fallback is important. Open Library has deeper coverage of older British editions, classroom textbooks and small-press fiction. By stitching the two sources together, we cover well over ninety percent of the books our sellers list.
Step two: in-browser barcode scanning
Typing a thirteen-digit ISBN is exactly the kind of friction that kills marketplaces. We use the device camera with the browser native BarcodeDetector API to read the barcode on the back of the book, with the open-source ZXing library as a fallback for iOS Safari and other browsers that do not yet ship the native API. Both options run entirely on the device, which means no images leave the phone and there are no per-scan API costs to worry about. The decoded ISBN feeds straight into the metadata lookup described above. From the seller perspective, they tap the camera button, hold the book in frame, and the listing form fills itself in.
For richer image work, such as gentle nudges about cover wear, we use a small Gemini Flash Lite prompt rather than a heavyweight vision API. It is cheap enough to run at scale and fits naturally with the rest of our AI tooling.
Step three: Google Identity for friction-free login
The single biggest drop-off in any marketplace is the signup form. Google Identity lets a buyer or seller create an account in one tap, with no password to remember and no email confirmation step. We pair it with email signup for users who prefer a password they control, and with a handful of other community-friendly social providers, including Facebook, LinkedIn, X and Discord, so readers can sign in with whichever identity they already trust.
Crucially, we do not use the social login as an excuse to over-collect data. We ask for a name and an email. Anything else, we earn the right to ask for later, when the user actually needs it.
Step four: Gemini for category and search
Once we have the metadata, we still have to put the book somewhere. We use a lightweight Gemini model to categorise listings into the ReReadz taxonomy. This is not vibes-based AI: we constrain the model to a fixed set of categories and validate the result before saving. If the model is unsure, we leave the category blank and let the seller decide.
We also use Gemini to power features like camera-based search, where a buyer can take a photo of a book in a charity shop and find used copies on ReReadz. The cost discipline matters here. Gemini Flash Lite is cheap enough that we can run these features at scale without the unit economics falling over.
Why we did not build it ourselves
We could have built our own metadata index, our own barcode scanner, our own login system. We chose not to. Here is the simple framing we used.
If a capability is genuinely differentiated for our users, we build it. The condition rubric, the seller storefront, the bundling logic, the trust signals, all of these are ours. If a capability is undifferentiated heavy lifting, we lean on the platform. Reading a barcode and looking up an ISBN is not where we add value. The value is in the curated, community-led marketplace that sits on top.
The hard parts of integrating with third parties
Working with external APIs sounds easy and is not. We have learned a few lessons worth passing on.
Cache aggressively. Public APIs have rate limits and outages. We cache successful metadata lookups in our own database so a second seller listing the same ISBN gets an instant response and we do not pay the API tax twice.
Design for failure. Every external call has a timeout, a retry policy and a graceful fallback. If Google Books is down, our listing flow keeps working with Open Library and manual entry. The user should never see a generic error and be left stuck.
Respect the user data. Just because Google can give us a profile picture does not mean we should display it. We keep social login data minimal and explain clearly what we use.
Watch your costs. AI calls bill per request. Without sensible quotas, an enthusiastic seller bulk-listing five hundred books could surprise you with a four-figure bill. Set hard caps and monitor them.
What this means for sellers and buyers
For sellers, the practical effect is that listing a book takes about fifteen seconds. Scan the barcode, confirm the condition, set the price, done. That speed is the difference between a shelf cleared in an evening and a project that is still half-finished six months later.
For buyers, the effect is a catalogue with consistent metadata, accurate covers and reliable categorisation. Search works because the underlying data is clean. Discovery works because we can group titles, surface bundles and recommend related reads with confidence.
People also ask
Which Google APIs does ReReadz use?
Primarily Google Books for metadata, Google Identity for login and Gemini for category classification and image-based search. Barcode scanning runs on-device using the browser BarcodeDetector with a ZXing fallback.
Is my data shared with Google?
We use Google services for specific features only. We do not pass personal data beyond what is necessary, and we never sell user information.
What happens if a book is not in Google Books?
We fall back to Open Library, and if that also fails, the seller can enter the details manually. The listing flow always works.
Do I need a Google account to use ReReadz?
No. Google sign-in is optional. You can sign up with email, or with Facebook, LinkedIn, X or Discord if you prefer.