ONIX 3 Feed Checker
Check your ONIX book metadata feed before retailers see it.
What it does
Give it links to your ONIX files and it checks each one against EDItEUR's published ONIX schema and code lists. It then runs checks the schema can't do: ISBN check digits, dates that don't exist, prices with no currency, record references used twice, and records with no publishing status, contributor or ISBN. You get one row per problem, with the product's record reference, the line number and where in the record it is, so you can find each problem quickly. This matters because retailers and aggregators load feeds by machine, and a record they can't read may not go on sale.
What you get
- One row per problem: record reference, line number, field path (where the problem sits inside the record, such as Product[5]/ContentDetail/ContentItem[1]), error or warning, a message and the rule or standard it comes from. For schema problems the message is the schema validator's own wording.
- A readable report (HTML and Markdown) with a summary per file and the problems grouped by kind.
- A single "no issues" row for a clean file, and a clear row for a link that didn't download, so one bad link doesn't stop the rest.
- Works with either tag style (reference names or short tags) and detects which one automatically. Accepts .xml, .xml.gz or a .zip of several files, and reports on each file separately.
- Results as a table you can export to CSV, Excel or JSON.
Example: two problems from real ONIX 3.0 feeds
| Line | Where | Message |
|---|---|---|
| 1433 | Product[5]/ContentDetail/ContentItem[1] | Element 'ContentItem': Missing child element(s). Expected is one of ( ComponentTypeName, ComponentNumber, TitleDetail ). |
| 25087 | Product[71]/ContentDetail/ContentItem/NumberOfPages | Element 'NumberOfPages': This element is not expected. Expected is one of ( ComponentTypeName, ComponentNumber, TitleDetail ). |
Best for
- Checking a feed before you send it, or after changing the system that exports it.
- Finding which records to fix when a recipient reports your file as invalid.
Not for
- A promise that Amazon, Apple, Kobo, Ingram or anyone else will accept your feed. Each recipient has its own extra requirements; this checks the ONIX standard and the rules listed on the Apify page.
- ONIX 2.1 files. It checks ONIX 3.0 and 3.1 only; a 2.1 file gets one row saying it isn't supported.
- Judging your descriptions, subjects or cover images. It checks structure, codes and the listed rules, not how good the metadata is.
Cost and how to start
- Open it on Apify Store and sign in, or create a free Apify account.
- Give it direct download links to your ONIX files (up to 50 per run) and start the run.
- Download a row for each problem, or the run's report.
Free from us. Apify bills its own small platform usage to your Apify account. Apify charges its own small usage fee to your account: about US$0.001 for a run checking three catalogue files when we tested it.
Questions
- My feed is on my computer. How do I check it?
- It can't read files from your computer. First put the file somewhere that gives a direct download link that works without a login (for example a temporary share link from your cloud storage), then paste that link. Files up to 200 MB are checked by default; you can raise the limit to 1,000 MB in the input. Large files need more run memory, which you set in the run options.
- Will it complain about things that are only warnings?
- Some checks are warnings, such as an ISBN not also sent as a GTIN-13, or no publication date. You can turn warnings off and see errors only.
- Where are my files processed and kept?
- Each file is downloaded into your own run on Apify and checked there. The file itself isn't saved; the problem rows and the report are saved in that run's storage in your Apify account, and the actor doesn't send them anywhere else. Apify deletes run storage automatically under your plan's data-retention rules, or you can delete it sooner: open the store under Storage in the Apify Console and use its Actions menu.
How we tested it
- Real catalogues, real problems. We ran the public ONIX catalogues of four academic publishers: 705 books in total, each exported as both ONIX 3.0 and 3.1. One catalogue came back clean in both versions. In the others it found chapter entries that ONIX 3.0 requires to have a title or type but that had neither. ONIX 3.1 allows this, so the 3.1 files passed. It also found a page count placed where the schema doesn't allow it, and books listed with no ISBN. We looked up examples of each kind of problem it reported in the files themselves, and each was really there.
- Planted errors were caught. We then put five mistakes into a clean 194-book catalogue: a wrong ISBN check digit, a product form code that doesn't exist, a date of 31 February, a price with no currency and a record reference used twice. It reported all five, on the right records, and found nothing else wrong in the file.