I built the API that published my 5 books on Amazon KDP

J Singerman — Mon, 02 Nov 2026 20:51:45 +0000

I'm a solo dev. I also write nonfiction books — ancient scripture, Apollo, declassified aerospace records, that corner of the shelf. I have five of them live on Amazon KDP as paperbacks right now.

The part nobody warns you about isn't the writing. It's the formatting. Specifically: turning a manuscript into an EPUB 3 file that doesn't embarrass you on a Kindle.

The pain

Every book meant the same miserable checklist:

Metadata — title, author, identifiers, language, all in the right XML, or retailers mangle your listing.
The OPF manifest — every single file in the book (every chapter, every image, every stylesheet) declared in content.opf, in order, spelled exactly right. Miss one and the whole archive is invalid.
The NCX table of contents — the navigation file Kindle actually uses. Hand-writing toc.ncx for a 40-chapter book is the kind of work that makes you question your life choices.
Typography that survives Kindle — embedded CSS that looks fine in a validator and then renders like a ransom note on an actual e-ink device. Drop caps, block quotes, tables: each one a small adventure.

I did this by hand for the first book. By the second, I was writing scripts. By the third, the scripts had become a thing with a name. By the fifth, it was an API.

That's the honest origin story. EpubCraft wasn't a product idea. It was me refusing to hand-write another NCX file.

Could I have used existing tools? Sure, and I tried. Desktop converters are fine until your book has real structure — parts, chapters, subsections, tables, epigraphs — and then you're fighting the tool's opinions about what a book should look like. Word-to-EPUB pipelines mangle nonfiction formatting in ways you only discover after publishing. I wanted something headless and deterministic: same manuscript in, same valid book out, every time, scriptable, no GUI clicking through export dialogs at midnight.

What I built

EpubCraft is a headless EPUB 3 and KDP-compliant document compiler. You POST it a manuscript — Markdown or HTML — and it hands back a valid EPUB 3 archive: metadata, OPF manifest, NCX table of contents, embedded CSS typography, all assembled correctly.

It runs on Vercel Edge, it's one of 16 production APIs I run behind a RapidAPI gateway, and every endpoint has automated test coverage. Here's what it does, endpoint by endpoint, in plain language:

POST /v1/compileEpub — the main one. Send your manuscript plus options (title, author, theme), get back a compiled EPUB 3 file. This is the whole pipeline: parse, validate, assemble manifest, build TOC, embed styles, zip it into a valid archive.
GET /v1/listThemes — lists the available typography themes. Pick the visual style without writing CSS.
POST /v1/validateManuscript — checks your manuscript before you compile. Catches the structural problems that would produce a broken ebook, so you fix the input instead of debugging the output.
GET /v1/downloadSampleEpub — grabs a sample compiled book so you can see exactly what the output looks like before you commit your own manuscript to it.

Nothing exotic. It just does the boring, exact, unforgiving work of EPUB assembly the same way every time — which is precisely what hand-formatting never does.

The determinism is the whole point, by the way. When Amazon flags something in your file six months later, or you need to push a corrected second edition, you re-run the same manuscript through the same pipeline and get the same book back, fixed. Try that with a folder of hand-edited XML and a prayer.

Proof

This isn't a demo. All five of my books went through this pipeline:

Before the Bible: The Dead Sea Scrolls, the Book of Enoch, and the Battle to Define Sacred Scripture
ANOMALIES BEYOND THE ATMOSPHERE: Evaluating Unidentified Objects, Rhythmic Flashers, and Orbital Trajectories in Gemini, Apollo, and Skylab Debriefs
Did We Walk on the Moon! The Apollo Hoax Paradox: Why faking the lunar landings was more difficult than flying them
Beyond Propulsion: The DIA's Advanced Aerospace Papers
The Black Ledger: 75 Years of Declassified Intelligence Records, Nuclear Incursions, and the Government's Secret UAP Paper Trail

Five real books, live on Amazon. The compiler that built them is the same one behind the API. If it can survive my 40-chapter manuscripts with tables, block quotes, and footnotes, it can survive yours.

A quick example

Here's what a compile request looks like. (Illustrative example — sample content, not a real book.)

curl -X POST "https://epub-craft-api.vercel.app/v1/compileEpub" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "My Sample Book",
    "author": "Jane Example",
    "language": "en",
    "theme": "serif-classic",
    "format": "markdown",
    "manuscript": "# Chapter 1\n\nIt was a dark and stormy night...\n\n# Chapter 2\n\n...and then the formatting just worked."
  }' \
  --output my-sample-book.epub

What comes back is a valid EPUB 3 archive — metadata set, manifest complete, NCX table of contents built from your headings, typography embedded. The thing you'd otherwise spend a weekend assembling by hand, returned in one call.

If you want to check your manuscript first:

curl -X POST "https://epub-craft-api.vercel.app/v1/compileEpub" \
  -H "Content-Type: application/json" \
  -d '{ "manuscript": "# Chapter 1\n\nHello?", "validate_only": true }'

(The exact request/response shapes are in the OpenAPI 3.0 docs on the RapidAPI listing — that's the source of truth, not this post.)

Try it

EpubCraft is live on RapidAPI with a free tier. Compile something, break something, tell me what the validator yells about.