Privacy. What we hold, and for how long.

Your manuscript is the most personal thing this product touches. This page says what we store, where it goes, and what closing your account removes and what it leaves behind. Where a thing is designed but not yet wired, it says that instead of writing around it.

What we store

What we store, and how long we keep it

Anything attached to your account is deleted when the account is deleted. The periods below are the separate rule for records that outlive a single account. A scheduled job runs those deletions daily, so where a period is named it is one we keep rather than one we intend to.

Your account: The email address you sign in with, and the name and pen name you give us. Signing in works by a link we email you, and the product never asks you for a password. Your email settings are here too: which kinds of message you want, and the time zone your browser reports, so a reminder arrives in your evening rather than ours.Kept while the account exists.
Your books: The brief you write, the outline, the chapters, anything you import, the covers, the rendered print files, and the preflight reports run against them. These live in our database and in our own file storage.Kept while the account exists. When you delete a book, its files are removed by our retention sweep, usually within a day.
Purchases and credits: Polar is the merchant of record for every purchase: it takes the payment, holds the card details, and charges and remits the sales tax and VAT. We store the customer id Polar gives us, each order's id, product, amount, currency and status, a plan's status and renewal date, which checkouts you started, and a ledger of every credit added, held and spent. We have no field for a card number and never see one.Kept while the account exists.
Payment event records: The raw notifications Polar sends us about an order or a plan, kept so a purchase can be reconciled if something goes wrong. They can hold your name, your email address, the billing address you gave Polar, your account id and your Polar ids.Deleted after 90 days. If you close your account first, every one naming you by your address, your account id or a Polar id is blanked then, and one that arrives afterwards is blanked as it arrives. An identifier under twelve characters is skipped on purpose, because a short string would match half the table.
An address you leave for pricing news: If you leave an address on the pricing page to be told when buying opens, we keep it and the name of the screen you were on.Kept until you ask us to delete it. Closing an account deletes it when it is the address that account signed in with.
Emails we send you: A record of each message we schedule for you apart from sign-in links: which message, which book it is about, when it was due, whether it was delivered, and the id our email provider gave it. The unsubscribe link in each message is stored only as a one-way hash.Kept while the account exists.
Your survey answer: If you answer the one question we ask after a download, whether Amazon accepted the files, we keep your answer and anything you chose to tell us about a rejection.Kept while the account exists.
Request counts: To stop anyone hammering the service we count requests per IP address, per browser and per account. What we store about the caller is a keyed one-way hash of the address, the browser cookie or the account, never the value itself.Kept for 24 hours, then deleted at the next daily sweep, so gone within two days.
Which pricing layout you saw: When we compare two ways of laying out the pricing page, which one your account or browser was shown, and whether you went on to buy or leave an address.For an account, kept while it exists. For a browser with no account, deleted after 30 days, except while the comparison it belongs to is still running, when it is kept until the comparison stops.
Model call records: One row per call to a model, holding what it cost and how long it took. It stores a hash of the prompt, never the prompt and never your text.Target retention 90 days.
One-time link identifiers: The record that stops a single-use link being replayed.Target retention 30 days.
Download records: Each time you download your book pack or your account data, we write down that it happened and how much was in it: counts and a size, never a second copy of what you downloaded.Kept while the account exists, and deleted with it.
The erasure record: When an account is erased we keep proof that it happened: a keyed hash of the account id, timestamps, and whether each registered provider confirmed. The key never reaches the database, so the finished record holds no address and no account id in the clear. For 90 days we also keep one-way hashes of the erased account's id and payment identifiers, so a payment notification that arrives after the erasure is blanked as it arrives.Deleted 365 days after a finished erasure; the payment identifier hashes after 90 days.
Analytics events: Page views and the named product events described under Analytics below, held by PostHog rather than by us, with the approximate location worked out from your IP address attached to them and to your analytics profile.Deleted when you close your account. A profile that is not tied to an account is deleted 12 months after it last sent anything, together with every event under it. Events from a visit that never signed in have no profile, and are kept as long as PostHog keeps events.

The cookies this site sets

None of them is an advertising cookie, none is sold or shared with anybody, and nothing on this site follows you to another one. The analytics cookie is PostHog’s and is described in its own section below; the other seven are ours, and four of them last an hour at most.

Your session: Set when you open a sign-in link and cleared when you sign out. It is what keeps you signed in, it cannot be read by page scripts, and it is Supabase's own.Names beginning sb-
A book started without an account: A random value that says which browser started a book on the free run, so that browser can come back to it and keep it. It names no person and cannot be read by page scripts. A book started this way is deleted seven days after it was started if nobody keeps it.ir_guest, 7 days
Analytics: PostHog's own cookie, which holds the anonymous identifier its events are grouped under. It is set by the analytics library described below, alongside the same value in your browser's local storage, and it is not set for a visitor who had opted out before the page loaded. Opting out part-way through a visit stops anything more being sent, but a cookie already set stays until you clear it.A name beginning ph_
The idea you typed before signing in: If you type an idea for a book on the first page and then go to sign in, the words you typed are held in this cookie so the brief can be filled in when you come back, instead of in the address bar where your history and any shared link would carry them. It cannot be read by page scripts.ir_idea, 1 hour, cleared once used
Keeping a book you started: A random value set when you press to keep a book you started without an account, which ties that book to the address you asked for so it goes to that account and to no other. It cannot be read by page scripts.ir_claim, 1 hour
Where to go after signing in: The page to return you to once you open your sign-in link.ir_next, 1 hour
An email change you asked for: A note that this browser asked to change the account's address, so the account page can say a change is waiting without revealing whether an address is already registered.ir_email_change, 1 hour
Whether the bar says Books or Sign in: One character saying whether this browser holds a session, so the pages that are served from a cache can draw the right two words at the top right. It holds no identity, it is readable by page scripts because that is the only way the bar can use it, and nothing else in the product reads it.ir_nav

Where prompts are sent from

Every prompt is assembled and sent from our servers, never from your browser

The browser never holds a prompt and never holds a model key. Your brief, outline and chapters go from our server to OpenRouter, which routes each call to the model provider that writes that stage. Nothing about your book is sent from your browser to a model provider.

Your text is held in the tables that hold your book, in our own file storage as imports and rendered files, and it is staged for the render worker while a book is being built. That staged copy is deleted when the build succeeds; if a build fails, it stays with the book until you delete the book or your account. Our job and cost records store a hash of each prompt rather than the prompt, so the text is not copied into our operational logs.

Training

We do not train on your books, and here is the part we do not control

We do not train models on your content. We do not sell it or licence it to anyone. We do not read your manuscripts as a matter of course; a person here opens one when you ask us to look at something.

What we cannot claim is the whole chain. Your text passes through OpenRouter to whichever model provider writes that stage, and each provider has its own terms about training on data that reaches it. We are working through those terms provider by provider. When that review is done this page will name each provider and what its terms commit to. Until then, this section is the honest state of it rather than a settled promise about anyone but us.

Who else

Who else touches your data

These are the providers we configure, plus the model providers our gateway routes to. We update this list when we change a provider.

Supabase: Accounts, and the database and file storage that hold your books.We run it in the EU, in Frankfurt.
Google Cloud Run: The render worker that typesets your book, builds the print files, and measures them for the preflight report.We run it in the EU, in Frankfurt (europe-west3).
OpenRouter: The gateway that carries each prompt from our server to the model that writes the text.United States.
The model hosts: The companies that run the models writing your book. Our code picks the model for each stage; OpenRouter picks which company hosts that model for each call, and we record which one it was. So far that has been Anthropic's model on Amazon Web Services, and OpenAI's model on OpenAI's own service and on Microsoft Azure.United States. See the section below on training.
Vercel: Hosts the site and runs its server code, which is the code that reads your book out of the database and passes it on, so your text travels through it.We run the server code that reads your book in the EU, in Vercel's Frankfurt region. Your requests first reach Vercel's network at the location nearest you, and we have not confirmed where the sign-in check that runs before each page is processed.
PostHog: Product analytics. What we send it is described below.We run it on their EU project, in Frankfurt.
Resend: Sends our email: sign-in links, confirmations when you change your address, the reminder and progress emails you can turn off on your account page, and the one survey message after a download asking whether Amazon accepted the files. Resend keeps its own record of each message, including the address and the subject line.United States company. We have not pinned a region, so we do not claim one.
GitHub: Runs our nightly database backup and stores each copy for 14 days. The copy is made on GitHub's build machines and encrypted there before it is stored, with a key whose private half GitHub never holds, so the stored copy is unreadable to them. It holds the database rows, including your book's text and your email address, and none of your files.United States company. We have not pinned a region, so we do not claim one.
Cloudflare: Domain and DNS, and the forwarding behind our support address.Global network.
Google (Gmail): The mailbox our support address forwards to, so it holds what you write to us there, including any request about your data.United States company. We have not pinned a region, so we do not claim one.
Polar: Merchant of record for every purchase. Polar takes the payment, holds the card details, handles sales tax and VAT, and issues the receipt. What reaches them from us is the account id and the address the account signs in with, so the receipt can be sent and the purchase can be credited to the right account. On its own checkout page Polar asks for what it needs to take the payment and charge the right tax, such as your name and billing address. What reaches us from them is the order, the amount, the status and their own customer id, and the raw notification each of those arrives in, which can also carry your name and billing address and which we keep for 90 days. No card detail ever passes through this product.United States company (Polar Software Inc.). Its own policy says it may store data outside the EU, so we do not claim a region.
Sentry: Error reports. When something breaks, on our server or in your browser, a technical report of what failed and where in our code is sent here so we can fix it. A report carries no cookies, no request bodies and no email addresses; a web address in it is cut down to which page it was, with no secret link; and the wording of the error itself is withheld, apart from our own error codes, so no text of your book goes with it. We also ask Sentry not to record your IP address. Not switched on yet: until it is, nothing is sent.We use their EU data region, in Germany.

Where we chose the region, it is named above. Where we have not pinned one, the row says so rather than implying that everything stays in the EU. The short version: your books and files are stored in the EU, in Frankfurt, and typeset there, and the server code that reads them and passes them on runs there too. The model providers that write the text run in the United States, so your book does leave the EU.

Analytics

What the analytics see

We use PostHog for page views and for named product events: accounts, projects, generation, preflight, exports and purchases. Each event and each property we send is written down in a registry in our code before it can be sent, and the emitter drops anything not on that list. PostHog adds properties of its own on arrival, and the approximate location is the significant one. Session recording is off. Autocapture is off, which matters here more than usual: autocapture records the text of what you click, and in this product that text is your manuscript.

We derive an approximate location, country, region and city, from your IP address for product analytics, so we can see which countries and cities authors come from. We never ask your device for its location. PostHog works it out from the address your browser connects from and does not keep the address itself, which we check on a real session rather than take on trust.

It locates a connection, not a person. Behind a VPN, a company network or a mobile gateway it can be somewhere you are not. What comes back is a city rather than a street: with the continent, country, region and city it stores the time zone, the postal code, the latitude and longitude of that city, and its own estimate of how far off it might be.

It is attached to the events your browser sends and to your analytics profile, twice on the profile: where you are now, and where you first were. Closing your account deletes the profile and requests the deletion of its events, described under Closing your account erases it.

We keep analytics for 12 months. A job of ours runs daily and deletes analytics profiles that are more than 12 months old and that PostHog records no activity for in the last 12 months, together with every event under them, in batches, so a backlog clears over several days rather than in one go. It deletes whole profiles and never single events, so a profile the job does not select keeps its older events however old they get: for an account, closing the account is what deletes them, and for a visitor who never makes an account there is no closure either. A profile the job can see is tied to an account is left to that account’s own deletion. The deleting is ours to do because PostHog publishes a retention setting for session recordings and none for events.

The 12 months covers profiles, and a visit that never signs in does not get one: our analytics library makes a profile only for a signed-in account. The events of such a visit carry an anonymous identifier and the approximate location, sit under no profile our job can select, and are kept for as long as PostHog keeps events. We cannot delete them one visitor at a time, so we say so here rather than let the paragraph above cover them.

One honest detail, because we measured it rather than assumed it. The date the job reads is PostHog’s own record of when a profile was last active, and we have seen it lag behind a visit rather than update with it. That makes the job delete sooner than the strict rule would, never later: a long-lived profile that comes back after a quiet year can still be deleted on its next sweep. We would rather it erred that way, and we would rather say so than let the paragraph above read as more precise than it is.

Events our servers send rather than your browser have this turned off, because the address there is our hosting provider’s and the answer would be wrong. If your browser sends a Global Privacy Control signal, your browser sends no analytics at all and no location is worked out from it. Events our servers send are separate and are unaffected by that signal today, and none of them carries a location.

PostHog is the only third-party analytics service your browser talks to. If a content blocker stops that request, it stays stopped. We do not route it through our own domain to get around a blocker you turned on.

Your copy

You can download what we hold about you

There is a button on your account page that builds an archive of what your account holds and sends it to your browser. It is not a request you email us and it is not a form we answer in a month. It is a download.

Inside it: your account details and email settings, every book with its chapters, imports, covers, renders and preflight reports, your credit ledger, your orders, plan and checkouts as Polar reported them to us, your printed links and how often each was opened, the emails we scheduled for you, your survey answer, which pricing layout you were shown, and the actual files, both what you imported and every print file and cover we produced. There is a manifest listing the row count of every document and the SHA-256 of every file, so you can check that what arrived is what we sent.

It also tells you what it does not contain and why, in a readme inside the archive itself. Nothing is left out silently: each record we hold back is named there with the reason. Two of them can hold your personal details rather than your writing: the raw payment notifications Polar sent us, which can carry your name and billing address, and an address you may have left on the pricing page. Ask us at support@inkreadyai.com and we will send you those too.

The archive is built by reading the database as you, so it can only ever contain what your own account can see. Your print files are the one thing our server fetches on your behalf, from the folders of the books that reading returned, because the file store does not let a browser open them directly. We do not store a copy of the archive anywhere, and we never mint a link to it that someone else could follow. We do write down that a download happened and roughly how big it was: the Download records row above says what that holds and why.

Deletion

Closing your account erases it

Take your copy first if you want one: the download above is on the same page, and once the erasure runs there is nothing left for us to send you.

Deletion is self-serve on the account page, not a request you email us. Pressing it starts the erasure: the account and every project, chapter, import, cover, rendered file, preflight report, credit, order record and scheduled email are deleted from the database, then the file storage behind them is cleared, then each registered outside provider is asked to delete its copy. The erasure refuses to record itself finished until every registered provider confirms. Two are registered.

PostHog confirms that your analytics profile is gone, and so is the profile of any book you started before you had an account. The deletion of the events under them is queued at their end and finishes on their schedule, not in front of us.

Polar is asked to delete its customer record for your account with the option that anonymises it, which by Polar’s own description hashes your name and email address and clears your billing address. The same call cancels a monthly plan straight away. Polar keeps its record of each sale and of each checkout you started, because as the merchant of record it has to keep that for tax, and those records still carry the account id we gave it and the address typed at checkout. If Polar cannot be reached when you close the account, the erasure stays open and our sweep keeps asking until it can; until then a plan can still renew.

Two more are named in our own code and deliberately not called, each with the reason written down. Error monitoring, which is Sentry once it is switched on, because no report it receives carries your account, your email address or your IP address, so it holds nothing filed under you; a report can name a book’s id inside a web address, which points at nothing once the book is deleted. And our email provider, Resend, which sends your sign-in links, the survey message and the reminder emails without creating a contact record, and which the key we hold can only send through: it cannot read or delete anything there. That is a real gap and we would rather say so. Resend keeps its own copy of each message, including your address, the subject line and the body, which can carry a book title and the links in the message, and those age out on Resend’s schedule, not ours.

What reached a model provider does not come back either. Your text went through OpenRouter to the provider that wrote each stage, and whatever those companies keep under their own terms is outside what closing your account can reach. The training section above says what we know about that and what we do not.

If any step does not confirm, the closing page says the erasure has not finished rather than telling you it is done, and our own sweep keeps retrying the steps that are left until each one confirms. If a book of yours is being typeset at the moment you press delete, nothing is deleted and you are asked to try again in a few minutes, because the typesetter would otherwise write its files back after we had cleared them. Ask us at support@inkreadyai.com if you want confirmation.

Some records outlive the account. Apart from the nightly backups, none of them is your book:

The erasure record: A keyed hash, timestamps and per-provider outcomes. It is the proof the erasure ran. While a run is unfinished it still holds the identifiers the retry needs; those are cleared the moment it completes.
Payment event records: Not owner-scoped, because a payment notification can arrive before an account exists and must survive after it does not. They join the erasure by redaction rather than by deletion, and the row above says what redaction does not reach.
Nightly backups: Once a night we take an encrypted copy of the database, and each copy is deleted after 14 days. A copy taken before you closed your account still holds it, so an erased account survives in our backups for up to 14 days. The copies hold database rows only, not your uploaded or printed files.
Printed short links: A paperback carries its URLs forever. The link code stays reserved so it can never be handed to a stranger's page, and it stops resolving. Its owner, its destination and its click records are erased.
Service logs: Our hosting provider (Vercel), our database provider (Supabase) and the render worker's platform (Google Cloud) each keep short-lived operational logs of requests and jobs, which can include your account id, and Supabase's own sign-in logs can include your email address. Closing your account does not reach them; they age out on each provider's schedule.
A claimed guest book's marker: If you kept a book you started without an account, a one-way digest of that browser's cookie stays for 30 days so the same cookie cannot claim a book twice. It names no person.

Not settled

What is not settled yet

Terms of use, an acceptable-use policy and a copyright statement are drafted and waiting for legal review. They are not published, and nothing on this site treats them as in force. A data processing agreement is drafted alongside them and is not available yet.

Also unfinished, and listed here because you would otherwise have to take the rest on trust: the review of each model provider’s training terms, and an erasure step at our email provider, which the key we hold today cannot perform.

This page is written by the people who built the product and has not been reviewed by a lawyer. It describes what the code does today, including the parts that are not finished. It is not legal advice, and it does not stand in for the terms of use above. Questions, corrections and erasure problems go to support@inkreadyai.com.