Service access
Up to 50 book deliveries a month, with no daily limit — far more than an author with a shelf of titles will use.
You keep your own Apple account and your own royalties. We handle the delivery: the package Apple requires, the metadata, the 51 territory prices, the validation and the upload itself.
Your App Store Connect key is never stored — uploaded for one delivery and destroyed when it ends. Every book is validated with EPUBCheck and checked against its own metadata before anything reaches Apple, so a rejection is something you read here in seconds rather than from Apple hours later.
Only successful deliveries count. A dry run is free, and a failure is refunded.
Author
Up to 50 book deliveries a month, with no daily limit — far more than an author with a shelf of titles will use. You keep your own Apple account and your own…
What's included
- apple-service (write)
Choose your editions — add as many as you like
Author
MXN 830.99
Press
MXN 6763.99
Instant download after payment. Yours to keep — re-download it any time, on any device, free.
Have an invite code?
Type it here — you and your friend both get a free cycle when you subscribe.
Features
Fifty a month, no daily limit
The month is the only rule; how you spread it is your business. For most authors that is more than a year's publishing, which is the point — the allowance is a guardrail on a shared queue, not a ration.
Your account, your royalties
You are the publisher of record. Books go to your own Apple account under your own provider, and Apple pays you directly. We are the delivery, not a middleman on your revenue.
Your key is never stored
Apple requires an App Store Connect key. You upload it for one delivery and it is destroyed when that delivery ends. We keep only a SHA-256 fingerprint, so we know which credential did what without ever holding one.
One price, 51 storefronts
Set one price in US dollars. We expand it across every Apple territory, adjusted for local buying power and that day's rates, and show you the whole table before anything is sent.
It fails here, not at Apple
Every book is validated with EPUBCheck and checked against its own metadata — the ISBN in the file has to be the ISBN on the listing. A problem is a sentence you read in seconds, not a rejection notice hours later.
Eleven gates before your Apple account
The destination is derived from who owns the book and can never be supplied by a request. Apple itself must confirm the credential. You name the account you expect, and a mismatch refuses the delivery.
Publishing to Apple Books — what you are buying, and what happens to your key
Are you my publisher, or my distributor?
Neither. We are a delivery service.
You remain the publisher of record. Your books go to your own Apple account, under your own Apple provider, and Apple pays you directly. We never take a share of your royalties and never sit between you and Apple's payments.
We also do not review, edit, translate or endorse your books. What you send is what we deliver.
Do I need my own Apple account?
Yes, and you must already have one. You need an Apple Books account with App Store Connect access, and an App Store Connect API key (a
.p8 file) issued from it.
We do not create an Apple account for you and cannot obtain one on your behalf. That is the whole point of the design: the account is yours, so the listings and the royalties are yours.Do you store my App Store Connect private key?
No. There is no "remember this key" option, and that is deliberate.
Your
.p8 is uploaded for one delivery. It lives in that delivery's own temporary working directory — a RAM-backed tmpfs, deliberately not on any path that gets backed up — and it is destroyed when the delivery ends, on every exit path including a crash.
This service therefore has no credential store to breach. There is no record anywhere in it that can be turned back into a usable Apple credential.Then how do you know which key did what?
We keep a SHA-256 fingerprint of the key — a digest of its bytes, which cannot be turned back into the key. It is the only thing about your private key that outlives a delivery.
It earns its place: it answers which credential performed this delivery, and it is the only check that can notice one credential being used by two different accounts. A credential belongs to one account; two accounts on one key means one of them could publish into the other's listings, so we refuse it.
What do you store, then?
Two things.
The credential identifiers — key id, issuer id and Apple provider short name — as one indivisible record, so a delivery can be routed to your account. These are identifying, not secret.
A permanent record of every delivery: when it ran, which book and which ISBN, which account it went to, which key id and fingerprint were used, who requested it, what was in the package (file sizes and digests, never the files), how it was validated, and how it ended — including the attempts that were refused. That record is how a delivery can be proven after the fact, and it is deliberately not deletable.
We do not keep your EPUB, your cover, or your key.
How can you be sure my book goes to my Apple account and not someone else's?
Because the destination is never something a request can name.
No function in this service accepts a provider argument. The Apple account is derived from who owns the book, server-side, every time — and there is no default and no fallback to Publifye's own account anywhere in the codebase. A missing destination is a refusal, not a guess.
On top of that, eleven independent gates stand between a request and your Apple account. They are not layers of one check: each is derived from a different source — our ownership record, Apple's own answer, your stated intent, and the package's own contents — so disabling any one of them still leaves a cross-account delivery refused by another. That is a property the test suite proves by switching each gate off alone.
The last of them runs after the upload: we read back which account Apple actually recorded the content under, and halt on a mismatch.
Why do I have to type the account name every time?
Because a confirmation you cannot skip is worth more than a warning you can.
Before any upload you name the Apple provider you believe you are publishing to. It is checked against the account we derived from the book's owner. It cannot select an account — it can only cause a refusal if it disagrees with the one we resolved.
Apple itself must also confirm that your credential may deliver for that provider before anything is sent.
What is checked before my book reaches Apple?
Every delivery is validated here first, so a problem is a sentence you read in seconds rather than a rejection notice from Apple hours later:
- the EPUB is validated with EPUBCheck, the industry-standard validator — a fatal or an error stops the delivery
- the book is checked against its own listing: the ISBN, title, language and author inside the file must match what we are publishing it as. Each half can be perfectly valid on its own and still describe different books, and the reader is otherwise the one who finds out
- the package is built by us from your book's facts — we never accept an uploaded metadata file
- the subject codes are validated for existence and for not having been withdrawn, not merely for shape. A typo'd code is filed as a different subject without complaint
- the package must be addressed to this book's ISBN, or it would be modifying a different listing
These checks are not a guarantee that Apple will accept your book. Apple applies its own review and may reject or remove content for its own reasons.
One price, 51 storefronts — how does that work?
You choose one number: a base price in US dollars.
We expand it across all 51 Apple territories. Each one is adjusted for local buying power, converted at that day's rates, and then matched to Apple's own price-tier ladder for that country — which is a tier table, not a currency conversion.
You can see the whole table before anything is sent, and previewing it contacts nobody and changes nothing.
How long does a delivery take?
Longer than you might expect, and on purpose.
Uploads to Apple run one at a time across the entire service. That is not a tunable — it is deliberate, because Apple's delivery service is not something to run many of at once. Deliveries queue in the order they were submitted, and a large batch is delivered steadily rather than instantly.
Waiting behind other work is normal operation, not an outage. While a delivery runs you can watch its full output live, so "queued behind something" always comes with an answer to what.
Can I send a whole backlist in one week?
Yes. That is expected use, not abuse.
Every paid plan carries a monthly allowance and no daily limit — how you spread it across the month is your business. A daily cap would bite hardest exactly when you migrate a backlist, which is the week you sign up, so there isn't one.
The uploads themselves still run one at a time, so a large batch arrives steadily over hours rather than all at once.
What actually counts against my allowance?
One successful upload of one book. Nothing else.
Checking status, reading logs, browsing your history, previewing prices and asking what you have left are all free and never counted.
A delivery that fails is refunded to the same allowance period it was charged to. A delivery our own service refused before ever contacting Apple was never charged at all. The allowance is spent on books that actually reach Apple.
Can I test a book without spending a delivery?
Yes — a dry run. It validates a whole package, against Apple, and sends nothing.
On every paid plan dry runs are uncapped: a customer being careful before spending a delivery is exactly the behaviour we want. On the free pass they are capped at 25 a day, which is a guard against a runaway loop rather than a ration — it is far more than anyone verifying a real book will use.
A dry run never costs a delivery, whether it comes back clean or broken.
What are the allowances?
| Plan | Allowance |
|---|---|
| Free | 5 deliveries per year |
| Author | 50 deliveries per month |
| Press | 800 deliveries per month |
| Unlimited | by arrangement |
Monthly allowances reset on the 1st, UTC. The free pass renews on 1 January — it is five a year, not five for life, and it does require a Publifye account, because we cannot count deliveries for someone we cannot identify.
You can ask what you have left at any time rather than discovering it by being refused.
Why is "Unlimited" a conversation and not a bigger number?
Because above the Press plan the constraint stops being commercial and becomes physical. Uploads to Apple are serialised across the whole service, so an unlimited arrangement is a question about throughput and scheduling, not about a figure on a page.
Tell us roughly how many titles a year, whether it is a one-off backlist migration or an ongoing list, whether you have one Apple account or several, and whether you need a fixed window each week. We reply personally with a proposed price — and if we cannot carry your volume we will say so rather than sell it to you.
Can I see what went wrong?
Yes, in full.
The complete output of a run streams while it is still running, so you can watch it, and it is kept for 72 hours afterwards. Private key material never appears in it — the output is redacted line by line, before it is stored anywhere.
A refusal from our own checks says exactly what refused and why, in a sentence written for you rather than for a pipeline. Jobs stay readable for 7 days, and the permanent delivery record outlives both.
How do I find out which of my books Apple actually has?
By reconciliation, because Apple will not list a catalogue.
There is no "show me everything I have" call — every Apple status mode requires the identifiers up front. So the only honest answer is to present your own ISBNs and record which ones Apple recognises, and the result is only as complete as the list fed into it.
It runs asynchronously and paces itself deliberately: it yields the upload slot to real deliveries between batches, so a full scan takes tens of minutes and never gets in the way of publishing. A scan cut short can be resumed rather than repeated.
Can I drive this from Claude or another AI?
Yes — that is the primary interface, and the web console is the secondary one.
The service exposes an MCP endpoint at
https://apple.publifye.pro/mcp, speaking OAuth 2.1 with dynamic client registration, so most clients need nothing but the URL. There are tools for asking what is stopping a book, opening a delivery, submitting it, polling it, reading its log, querying the permanent record by ISBN or by book, and checking what allowance you have left.
The Connect page walks through Claude web and desktop, Claude Code, Cursor and any other MCP client.Does it matter which kind of App Store Connect key I have?
Yes, and it is the most common reason a first delivery fails.
Apple issues keys in two kinds — one issued to a team, one issued to a single person — and they are not interchangeable. The service needs to know which you hold; get it wrong and the delivery fails for a reason that looks like nothing at all.
You do not have to work it out yourself. Record the kind when you set up your credential, and if it disagrees with the key you upload, the delivery is refused with a message that says so plainly rather than failing somewhere downstream. Ask us if you are unsure — it takes one look at what Apple sent you.
What happens if I get stuck in a loop of failures?
After 100 consecutive failed requests with no success between them, a caller is paused for an hour.
The threshold is consecutive rather than cumulative on purpose: a hundred failures spread across a year is somebody learning the service, and a hundred in a row is an automated retry loop. One success clears the count entirely.
It is not a quota. It costs you nothing and it exists to stop a misbehaving script from occupying a queue everyone shares.
Do you promise 100% uptime?
No, and we will not pretend otherwise.
We take the service down when it needs it — backups, upgrades, security patching. A service that is never taken down is a service nobody is looking after, and we would rather it be looked after. Backups run daily and take the fleet down for roughly ten minutes.
Deliveries queue rather than fail during that. We also depend on Apple, whose own service has its own availability and its own maintenance, entirely outside our control.
There is no service credit, refund or penalty attached to downtime, queue depth or delivery latency. Your subscription buys access and volume, not a response time. We schedule disruptive work outside Norwegian business hours where we can.
What happens to my books if I cancel?
They stay on Apple. They are in your account and were never ours to withdraw.
Cancelling stops future deliveries and stops the next renewal. Subscriptions are billed yearly in advance and are not refunded — not pro rata, not for unused allowance, not on a change of mind.
Because the service begins immediately, completing a purchase means expressly asking for immediate supply and thereby giving up the 14-day right of withdrawal (angrerett). If you are not willing to give that up, do not complete the purchase. That is a no-refund policy, not a claim to rights the law does not allow: where we have materially failed to provide the service, tell us and we will put it right.