Send us an ONIX for Books XML file to add metadata to books already in your Cashmere catalog. ONIX does not create a book or upload its content. We match each product to a book in your organization by its ISBN-13, GTIN-13, or proprietary ID, and apply the metadata when that book is available.
How to send ONIX
Send an uncompressed XML file by either route:
- SFTP: Connect an SFTP Server, then place the file in
the configured directory. The filename must end in
.xmlfor the ONIX route. - API: Use a publisher organization's read/write API key with access to
metadata-records. To list a book's records withGET /api/v2/omnipub/{uuid}/metadata-records, the key also needs access toomnipub. Send a multipartfileupload toPOST /api/v2/metadata-records, or send JSON with a public HTTP(S)file_urlpointing to the XML. The API recognizes ONIX from the XML content, regardless of the filename extension. Private or internal URLs are refused.
For example, upload a local file with:
curl -X POST "https://cashmere.io/api/v2/metadata-records" \
-H "Authorization: Bearer YOUR_PUBLISHER_API_KEY" \
-F "file=@publisher_onix_20260930.xml"
The API also accepts Content-Type: application/json with
{"file_url":"https://publisher.example.com/publisher_onix_20260930.xml"}.
Use a descriptive filename such as publisher_onix_YYYYMMDD.xml: the API
returns its basename as source_file, which helps you trace a submission or
record back to a feed. For a file_url submission, source_file stays null
until the background job has downloaded the file. Submit the XML itself;
compressed files are not accepted as ONIX inputs by the API.
What to send
- ONIX 2.1, 3.0, or 3.1 XML, using reference tags or short tags, with or without an ONIX namespace. Use an
<ONIXMessage>or<ONIXmessage>root. - Declare the XML encoding. UTF-8 is preferred; ISO-8859-1 and UTF-16 are also recognized during delivery.
- A
ProductIdentifierwithProductIDType15(ISBN-13) for every product. Use the same ISBN-13 as the book in your catalog. We also read GTIN-13 (03) and proprietary (01) identifiers, but an ISBN-13 is the reliable way to match a book. If a product has more than one proprietary ID, only the first is used, so list your own ID first. ISBN-10 (02) alone cannot identify a product for delivery. For ONIX 2.1, put identifiers inProductIdentifiercomposites; the flatISBNandEAN13elements are not read. - Send descriptions in
TextContentwithTextType03(full description) or02(short annotation). We use03when both are present. Send publication dates asYYYYMMDD(dateformat00); other formats are retained as supplied rather than normalized. - As a delivery guideline, keep each uncompressed XML file at or below 40 MB and split larger catalogs into multiple messages. This is not a hard limit; large API submissions can take many minutes and the background job has a one-hour timeout.
For edited volumes, contributors inside ContentItem are treated as chapter
contributors, not book creators, and a ContentItem's descriptions and
subjects are not used for the book, so chapter subjects do not become book
tags. Series editors and subjects inside Collection (ONIX 2.1 Series) are
not used for the book either.
Metadata we use
When a product matches a book, these nonempty values can update its main book details:
| Book detail | ONIX data used |
|---|---|
| Title and subtitle | Product TitleDetail with TitleType 01 and TitleElementLevel 01; ONIX 2.1 Title |
| Creators | Contributor names, in document order. Roles and SequenceNumber do not filter or reorder them. |
| Publisher | PublisherName (PublishingRole 01 recommended); otherwise another named publisher or the imprint name |
| Publication date | PublishingDate with PublishingDateRole 01; otherwise the first date. ONIX 2.1 uses PublicationDate. |
| Cover image | SupportingResource with ResourceContentType 01; ONIX 2.1 MediaFileTypeCode 04. We store the image URL but do not fetch it. |
We also keep these details with the book's ONIX metadata: record reference,
notification type, publishing status, product form, product form detail and
description, imprint, copyright year, description (TextType 03 or 02),
series, identifiers, and subjects. A series title comes from a Collection or
TitleElementLevel 02; it does not replace the product title. The
description is retained as ONIX metadata rather than replacing a main book
field.
ONIX codes and how we handle them
| Codelist | Values used | Result |
|---|---|---|
| 5 — ProductIDType | 01 proprietary, 02 ISBN-10, 03 GTIN-13, 15 ISBN-13 |
Identifiers; delivery chooses ISBN-13, then GTIN-13, then the first proprietary ID. |
| 15 — TitleType | 01 |
Product title. |
| 149 — TitleElementLevel | 01 product, 02 series |
Title or series. |
| 17 — ContributorRole | Ignored | Every contributor name is eligible to become a creator, regardless of role. |
| 45 — PublishingRole | 01 recommended |
Publisher name. |
| 163 — PublishingDateRole | 01 preferred |
Publication date. |
| 55 — dateformat | Ignored; send 00 (YYYYMMDD) |
Eight-digit dates are normalized to YYYY-MM-DD; other date strings are kept as supplied. |
| 153 — TextType | 03 preferred, else 02 |
Description. |
| 158 — ResourceContentType | 01 |
Front cover URL; ONIX 2.1 uses MediaFileTypeCode 04. |
| 27 / 26 — SubjectSchemeIdentifier | 10 BISAC, 12 BIC, 93 Thema, 06 MeSH, 20 keywords |
Subjects. ONIX 2.1 also reads MainSubject, BASICMainSubject, and BICMainSubject. |
| 1 — NotificationType | 05 |
Delete notice is stored but does not delete or update a book. Other notification types can be applied. |
Supported coded subjects can become book tags. Keywords (20) are kept as
metadata but do not become tags. Other subject schemes, including Thema
qualifiers and proprietary schemes, are not extracted.
We do not use prices, availability, supply details, measurements, extent,
audience, rights territories, ProductFormFeature, related products, or ONIX
2.1 OtherText descriptions. Other identifier types can be retained in the
ONIX metadata but cannot be used to identify a delivery record.
What happens after delivery
Each product with a usable identifier is stored as a metadata record.
Applied means we found an active book with the matching ISBN in your
organization and updated its metadata. Received means we stored the record
but did not apply it yet, usually because no matching active book is available.
Received records can be applied when a matching book arrives, including when a
book is replaced. A record matches a book by ISBN-13, or by a proprietary ID or
GTIN-13 equal to the book's external_id.
Superseded means an older ONIX record was replaced when a newer record
applied for the same identifier or book. Sending the same file again creates
new record rows; an older received record is superseded only once a newer
record applies.
Delete notices (NotificationType 05) also count as received; they are never
applied as deletions.
A product without an ISBN-13, GTIN-13, or proprietary identifier is not stored.
It may count as a product error, or be skipped if no main book details were
found. Valid products in a mixed file can still be received or applied. For
SFTP, a file with no products or no usable identifiers is recorded as an ONIX
ingest error. For the API, a file whose products all lack usable identifiers
can still show succeeded with errors equal to records. Check the counts,
not only the submission status.
Check an API submission
POST /api/v2/metadata-records returns HTTP 202 with a submission id.
Processing runs in the background and may take many minutes. Poll
GET /api/v2/metadata-records/submissions/{id}: the status moves from queued
to running, then succeeded or failed. The records, applied,
received, and errors counts are null until processing finishes. A failed
submission includes an error message.
Use GET /api/v2/metadata-records?submission_id={id} to list the records from
that submission. The list can also be filtered by record_type, status, or
identifier; use the normalized ISBN-13 without hyphens for an ISBN filter.
GET /api/v2/metadata-records/{record_id} includes the normalized ONIX
payload. To see records for one book, use
GET /api/v2/omnipub/{uuid}/metadata-records.