Google Play Books Integration

For a publisher or aggregator with more than a handful of titles, hand-entering each book's metadata, pricing, and territory rights in the Partner Center UI does not scale, and it creates the same problems e-commerce sellers face with manual catalog entry: inconsistent formatting, stale prices, and titles that silently fall out of sale because a required field was missed.

An automated feed keeps bibliographic data (title, contributors, identifiers) and commercial data (price, sales territory, availability) synced from a single source of truth, and lets Google's crawler pick up changes on a recurring schedule instead of requiring a manual re-upload every time a price or rights window changes.

This is the mechanic that makes Google Play Books structurally different from a typical product feed: metadata and commercial terms are split into two separate ONIX files per title collection. The bibliographic ONIX (referred to as "full" or "-full") carries descriptive data — title, contributors, language, subject/genre — and does not typically include sales rights or pricing. The rights ONIX ("-rights") carries the sales rights and supply detail: which territories a title can be sold in, and at what price.

On the automated-fetch server, these live in a directory named onix/, in collection subfolders named <collection_code>-full and <collection_code>-rights, alongside a separate ebooks/ directory for the actual EPUB/PDF/cover files (named by the plain <collection_code>). Google also supports a csv/<collection_code> path as an alternative to ONIX for the same automated fetch mechanism.

For automated content fetching, Google accepts ONIX 2.0, ONIX 2.1, or ONIX 3.0 XML files (UTF-8 encoding is strongly recommended for 2.1 and 3.0), retrieved by Google's crawler from a publisher-hosted server over HTTP, HTTPS, SFTP, FTP, or Google Cloud Storage. A CSV metadata format is also accepted as an alternative to ONIX under the same fetch mechanism — the same CSV files that can be uploaded manually in the Partner Center can instead be delivered by automated fetch.

Within ONIX, the ProductForm code must be one of EA, EB, EC, or ED for a record to be used to create an entry in the Partner Center at all — any other value and the record, including its price, is not ingested. Aggregators and distribution platforms acting on a publisher's behalf can be authorized as a Client Service Provider via a signed Publisher Consent Form.

Requirements differ by whether a field lives in the bibliographic (full) or rights ONIX file. The table below covers the fields Google's own documentation identifies as required, or as blocking a title from going on sale if missing.

1. Feedance maps your book catalog data — from a publishing CMS, bookstore platform, or spreadsheet — to the bibliographic fields Google's ONIX full feed requires: title, ISBN-13, contributor names and roles, language, subject/BISAC code, and page count.
2. Feedance builds the corresponding rights feed with sales territory, supply detail, and price-plus-currency data kept in sync with the full feed, so the two files stay consistent under the same <collection_code> naming.
3. Feedance hosts the resulting ONIX (or CSV, where that path is used instead) files at the onix/<collection_code>-full, onix/<collection_code>-rights, and ebooks/<collection_code> paths on an HTTP/HTTPS/SFTP endpoint that Google's crawler can reach.
4. You submit that endpoint through the Partner Center's automated content fetching request, and Google's crawler begins retrieving updated files on the schedule you request.

Because this format is materially different from a standard shopping feed, this integration is best suited to publishers or aggregators already committed to ONIX-based distribution rather than a first step into book publishing.

Google does not publish fixed crawl intervals. Partners request a preferred fetch schedule through Google's automated content fetching configuration form, and Google's crawler then retrieves files from the publisher's server "on a predefined schedule," downloading only files that have been modified or added since the previous crawl.

In practice, this means the rights feed (price, territory, availability) is the file worth updating on the tighter cadence, since it governs whether and at what price a title can be bought; the bibliographic full feed changes far less often and can typically run on a slower schedule.

1. Missing or invalid ISBN. "The ISBN book identifier is missing" or wrongly formatted — the book will not go on sale without it.
2. Missing title or author. Both are hard blockers for a title going on sale.
3. Missing or invalid RecordReference. The tag is missing or contains invalid characters.
4. Missing or invalid ProductForm. Must be EA, EB, EC, or ED; anything else means the record (and its price) is never ingested.
5. Format mismatch. The book format declared in the ONIX file doesn't match the format of the content file(s) actually submitted.
6. Missing sales rights. Title will not go on sale in the Play Store for any territory.
7. Missing or invalid NotificationType. Blocks processing of the record.
8. Missing SupplyDetail. Prevents the book from going on sale even if metadata is otherwise complete.
9. Missing SentDateTime in the ONIX header. Prevents the file itself from being processed.
10. Invalid price amount. One or more prices in the supply detail section fails validation.
11. Missing subject/genre, publisher, or summary (warnings, not blockers). Title still goes on sale but is excluded from Play Store category browsing or shows incomplete metadata to shoppers.

1. Complete every recommended field, not just required ones. Google's own guidance is direct on this: more complete metadata (subtitle, description, series info, BISAC subject) helps readers discover a title in search and category browsing.
2. Keep ONIX and manual Partner Center edits in sync. Google's documentation warns that the next ONIX feed submission overwrites any settings changed manually in the Partner Center UI — pick one source of truth per field.
3. Match ProductForm to the actual content file. A mismatch between the declared format and the uploaded EPUB/PDF is a documented, avoidable rejection cause.
4. Treat the rights feed as the higher-priority file to keep current. Price and territory errors block a sale outright, while most bibliographic gaps only degrade discoverability.
5. Use bulk spreadsheet editing for smaller catalogs. If your list is small enough that ONIX automation is overkill, the Partner Center's own bulk spreadsheet editing may be the simpler and equally valid path.

Is this the same as Google Merchant Center? No. Google Play Books Partner Center is a separate platform specifically for ebook and audiobook distribution and sale; it does not use Merchant Center's product feed schema.

Do I need ONIX for a small, single-author catalog? No. Google Play Books supports direct manual entry and spreadsheet-based bulk editing inside the Partner Center for catalogs that don't justify automated ONIX feeds.

Which ONIX version should I use? Google accepts ONIX 2.0, 2.1, or 3.0; UTF-8 encoding is strongly recommended for 2.1 and 3.0 files.

What ISBN format does Google require? ISBN-13, submitted as the ProductIdentifier value in the ONIX file.

Does this also cover audiobooks? Yes — Google Play Books supports the same automated content fetching and ONIX-based approach for audiobooks, with a narrator listed as a required contributor role.

What happens if my ONIX full and rights feeds disagree? Each feed governs its own domain (bibliographic vs. commercial/rights data); inconsistencies between them, or between either feed and manual Partner Center edits, are a documented source of the errors covered above.