Audience: Mixed. Useful for agents fielding merchant questions about book/photobook cover files, and for Tech-CS triage assessing whether a spine-related report is user error, a known limitation, or a genuine bug.
Purpose: Clarifies the dashboard-vs-API difference for book covers, the page-count rules for spine, and how to tell a user error apart from an actual bug when a merchant reports a spine issue.
Dashboard vs API: the key difference
This trips people up regularly, so it is worth stating plainly:
- Dashboard: the cover is one combined file, front + spine + back in a single asset, with spine width already built in.
- API: the spine is a separate asset from the cover. Spine dimensions must be queried via the API (the /products/spine endpoint), and they vary by page count and by the fulfilling lab.
If a merchant or a print guide seems to contradict this, check which route they are using (dashboard vs API) before assuming an error, the guidance is genuinely different for each.
Page-count rules
- Softcover books: must be between 24 and 300 pages. Below 24 pages, there is no printable spine, the book is too thin.
- If a merchant queries the spine endpoint below the minimum (e.g. 22 pages), a low or missing spine result is expected in principle, but see the known bug below on how this currently surfaces.
Known bug: empty-body 500 instead of a clean error
When a page count is out of range (e.g. below 24 pages for softcover), the spine endpoint should return a clear, documented response (as happens correctly in some cases, e.g. a layflat book returning "Requested product does not require a spine asset"). Instead, it currently returns an empty-body HTTP 500 in some SKU/page-count combinations, which looks like a system failure rather than an expected "no spine at this page count" result.
- What to check first: is the page count within the documented range for the SKU (24 to 300 for softcover)? If it is below range, that is the likely explanation, and the empty 500 is the known bug, not a new fault.
- What to do: do not treat this as a one-off. If a merchant reports a 500 on the spine endpoint, check their page count against the range before raising, and note in the ticket if it is an out-of-range case (the fix needed is a clean error message, not a spine calculation fix).
Quick triage checklist for spine reports
- Is the merchant using the dashboard or the API? (Different behaviour by design, not a bug.)
- If API, is the page count within range for the SKU? (Below 24 for softcover is out of range.)
- If in range and still failing, it is likely a genuine spine/asset issue, raise as normal.
- If out of range and returning an empty 500, it is the known error-handling bug, flag it as such rather than a new investigation.
Note: exact spine behaviour may vary slightly by cover type (hardcover/softcover/layflat) and by SKU. Where in doubt, the print guides for the specific SKU are the authoritative source.