send-to-kindle

Delivering a document to a Kindle. Covers what to produce, how it gets there, and the two failure modes that give no error message.

Producing the file is the pandoc skill's job — scripts/md2kindle-epub.sh turns markdown into a suitable EPUB. This skill starts at "the file exists".

Everything below is service behaviour, and it moves. Between 2022 and 2026 Amazon stopped accepting MOBI, started accepting EPUB, killed USB download of purchased books, and retired Word's Send-to-Kindle button. Statuses here are as of 2026-08; re-verify before relying on a dated claim.

Produce EPUB, not PDF

Delivery routes (status as of 2026-08)

Sending by email — three facts

1. Send the file as an email attachment to the reader's Send-to-Kindle address. Nothing else in the message matters.
2. Addresses are per device, not per account. An account with several registered Kindles has a separate ingress address for each, so delivery is granular. Amazon-facing device names are user-set and can be misleading — pick the target by a stable identifier (the address itself, or the device serial), never by display name.
3. The sender address must be pre-approved on the account's Approved Personal Document E-mail List. Mail from an unapproved sender is dropped silently — no bounce, no error, no delivery. This is the single most likely cause of "I sent it and nothing arrived".

The allowlist is separate from the ingress address; both live under Manage Your Content and Devices → Preferences → Personal Document Settings.

Confirming delivery — sending is not delivering

Ingress validation is asynchronous. Amazon accepts the SMTP transaction, then validates the document afterwards and reports failure by email. Everything observable at send time therefore proves only that the mail left, not that it arrived:

Scripted senders make this worse: an AppleScript send returns as soon as the message is queued, so a script that checks immediately after will always report success. Nothing about a queued message predicts what Amazon does with it two minutes later.

So: wait, then check for a bounce. Observed bounce latency is ~30–60 seconds. Waiting ~2–3 minutes and finding no bounce naming your filename is the verification. Anything faster is checking the wrong thing.

E999 — Send to Kindle Internal Error

Amazon's generic rejection. The wording names no defect and reads as transient, which is the trap: it is frequently a real, findable spec violation in your file.

Run epubcheck before theorising. It settles in seconds what the error message actively obscures.

Worked example, 2026-08-08 — one sender, one morning, all EPUBs from the same generator. The file that bounced twice, 3.5 hours apart, was the only one in the batch missing dc:title, a required element of the EPUB package metadata. Every file that carried a dc:title was accepted. The generator had made the title optional, so omitting one flag silently produced a spec-invalid book.

Two things that make this hard to see without the validator:

• Errors alone do not predict rejection. Accepted files in the same batch failed epubcheck too — broken internal links, undefined fragment identifiers. Amazon tolerated all of it. What it would not tolerate was the missing required element. Triage by severity and by REQUIRED-ness, not by error count.
• Surface plausibility misleads. The twice-failing file was the smallest and structurally simplest of the batch (36 KB vs 60 KB) and passed unzip -t cleanly. Nothing about it looked wrong.

So on E999:

1. epubcheck the-file.epub
2. Fix any violation of a required element (dc:title, dc:identifier, dc:language) and rebuild.
3. Resend. Note that re-attaching the byte-identical file is the one thing observed never to work — it bounced again in 16 seconds — which makes sense once you know the defect travels with the file.
4. Only if a validator-clean build fails repeatedly should you treat it as genuinely transient on Amazon's side.

The two silences are different

Both look like "nothing arrived", and they need opposite responses:

• No bounce, no delivery → an allowlist problem (see above). Amazon drops unapproved senders without a word.
• A bounce → the sender is approved; the message reached Amazon and was rejected downstream. Validate the file (above) rather than simply retrying.

A bounce is therefore mildly good news about your configuration. Once any document from a given sender has arrived, "no bounce" reliably means delivered for that sender.

Size ceilings

Text documents will not come near either. A document bundling archived source captures plausibly could.

Highlights only come back one way

Anything delivered via Send-to-Kindle is a personal document, not a Kindle Store purchase, and Amazon's cloud highlight ecosystem is structurally closed to it:

So the USB cable is not a convenience fallback here; it is the only mechanism. Plan around a manual step, or do not promise highlight round-tripping.

Common Mistakes

What this skill deliberately does not do

• It does not send anything. No sender script, no AppleScript, no SMTP helper, and no configuration contract for one. The send step is the three facts above, performed by a human in a mail client.
• It carries no addresses. Ingress addresses, approved senders, device serials, and keychain account names are personal values that belong in the operator's own private workspace, never in a published skill.