Publishing to Novelmint

Two categories are refused at the point of publishing, whoever submits them and whatever the agreement with the writer says.

• Adult content. Titles that classify as Adult are manuscript-only. They can be built, edited and exported, and they cannot be listed or sold. Classification is per chapter and rolls up to the book, so a single chapter can make a whole title unpublishable.
• Fan fiction. Work built on characters that belong to someone else is manuscript-only on a separate axis. The platform cannot be its distributor. This is about rights rather than quality, and it applies even where the writer holds every right they could hold in their own text.

Both are returned as machine-readable reason codes on the publish call (manuscript_only, fan_fiction_manuscript_only), so a catalog of a few hundred titles can be reconciled without reading English prose. A third code, derivative_unresolved, means content review has flagged characters that may belong to another work and the writer has to resolve it before the title can go live.

Books published on a writer’s behalf belong to the writer. Their account owns the series, the readers follow them, and the earnings are theirs. That does not change if the relationship with the partner ends later, and it is not something a partner can configure.

A partner publishing its own imprint owns its own titles in the ordinary way. The two modes are chosen per book at creation, and the consent machinery below applies only to the first.

• Readers pay per chapter. The writer keeps 70% of what they pay.
• Novelmint keeps 30%.
• A partner earns a 10% referral share on every title it brought here. That share comes out of Novelmint’s 30%, never out of the writer’s 70%. Accepting a partner costs a writer nothing.

The 10% is automatic and per book, which means one writer can bring books from several partners and each partner earns on the titles it actually brought. Nothing needs to be signed for it, and nothing needs to be configured.

A revenue-sharing agreement is a different instrument. It takes a share of the writer’s own 70%, it is negotiated and countersigned by the writer, and it is not part of the API. If a partner needs one, it is arranged by hand.

Partner earnings are held and paid on the same terms as an individual author’s. There is no separate partner schedule.

A partner asserting that it has an agreement with a writer is the partner’s word. Publishing someone’s book on that basis alone is not something the platform will do, so a title submitted on a writer’s behalf is ingested and then held: fully uploaded, entirely invisible, and waiting.

There are four ways the writer’s own consent arrives.

• Handoff. The writer clicks a button on the partner’s own site and is redirected here to confirm in their own session, then sent back. This is the fastest route and the strongest evidence, because the confirmation is collected first-hand rather than asserted.
• In-dashboard. A writer who already has an account accepts on their publishing page. No email is involved.
• Claim link. Where a writer has no account, an emailed link explains what has been sent and asks them to accept or decline.
• The writer asks. A writer can ask a listed partner to publish for them. That is permission, not an instruction: the partner still has to submit, and a writer asking does not override any contract between them.

When the writer accepts, everything held under that permission publishes at once, on the terms the partner already stated, and ownership moves to them in the same act. Permission is standing after that, so later titles publish immediately. The writer is emailed every time one does.

A writer can withdraw permission at any time, from their own publishing page. Withdrawal stops future submissions. It does not unpublish anything already live, and it does not stop the 10% on titles the partner brought, because that share records who brought the book rather than who currently has permission to send more.

Clearing attribution on an existing title is possible, and only on the written request of the writer. It is handled by hand and it is forward-only: earnings already paid are never rewritten.

A writer can also decline and block, which stops a partner contacting them again. A blocked writer’s email address is retained for that purpose alone.

The version is in the path: /api/publish/v1/. Every response also carries a Novelmint-Publish-Version header.

Inside v1 we may add endpoints, optional request fields, response fields and new error codes. Your integration has to ignore anything it does not recognize, and that single requirement is what lets v1 improve without breaking you.

Removing a field, renaming one, changing its type, or changing what an existing value means would be a v2, on a new path. v1 keeps serving, and any retirement would be announced in writing with notice rather than implied by a version number going up.

• Chapters are posted one at a time, up to 1 MB each. There is no whole-book endpoint.
• Ingestion is free. Nothing on this path debits credits.
• Covers are fetched from an HTTPS URL supplied on the publish call, and are reviewed after publication rather than before.
• Test tokens run the entire pipeline and stop short of publishing, so an integration can be exercised end to end without a real title reaching readers.
• Every response echoes the partner’s own catalog reference, and every write is idempotent, so a retried batch never duplicates anything.