Legal

Data Access Rules

Subscriber lists, memberships and billing. Last updated 3 September 2026.

In short: your subscriber list is yours alone, your membership and billing records are visible only to you (and to admins where a dispute needs checking), and money-related records can only be written by our servers after a payment provider has confirmed the event.

How the rules work

Every sensitive table in our database is protected row by row, not just page by page. The database itself checks who is asking before it returns a single row, so a rule cannot be bypassed by a clever request, a shared link, or a bug in a page.

Author subscriber lists

The readers who have signed up to an author's newsletter, including their email address.

Read: the owning author only (matched on the author's own account ID), or a site admin.
Update and delete: the owning author or an admin — used for tidying a list or honouring an unsubscribe.
Insert: never by a signed-in person directly. New subscribers are written by a trusted server process after the signup form is validated, so nobody can inject rows onto another author's list.
Logged-out visitors have no access to this table at all.

Author memberships (Scribe / Alchemist)

Which plan an author is on, its status, trial dates and renewal date.

Read: the member themselves, or an admin. Nothing here is public.
Write: only trusted server code reacting to a verified payment event. The app never lets a browser set its own plan or status.
Logged-out visitors have no access. Entitlement checks that a public page needs run through a narrow function that returns a yes/no answer, not the billing row.

Reader membership records and billing history

Membership rows and the audit trail of plan changes.

Read: the owner of the record only.
Billing audit history: admins only, so plan-change disputes can be checked.
Write: trusted server code only, from verified payment events.

Direct ePub sales and seller accounts

Sale records for direct author sales, and the author's connected payment account.

A sale is readable by exactly two people: the buyer and the selling author.
The connected payment account is readable by the author who owns it; nobody else, including other authors.
Sale rows are only created and updated by the verified payment webhook, never by the browser.
Sale settings (price, currency, whether a book is for sale) are managed by the owning author.

Common failure cases we avoid

A table with no policies at all

Turning on row level security without writing policies locks everyone out, and turning it off leaves everything readable. Every table above has explicit, named rules for each action.

Blanket public read access

A rule that says 'anyone may read' on a subscriber or billing table exposes email addresses and payment status to the whole internet. Public visibility is granted only to genuinely public things, such as a book listed for sale.

Trusting a value sent from the browser

Ownership is always taken from the signed-in account itself, never from a field in the request. Otherwise anyone could claim another author's subscriber list or another member's plan.

Letting the browser write billing state

Plan, status and paid amounts are only written by server code that has verified the payment provider's signature. A browser-set plan would be free-upgrade-by-request.

Using an admin/service key for ordinary reads

The privileged server key ignores all these rules. It is reserved for verified webhooks and maintenance jobs, never for loading a normal page.

Forgetting the owner's own read path

When a record is hidden from the public (a draft, an unapproved listing), the owner still needs a rule that lets them see it — otherwise authors report that something they created has vanished.

Read access granted but table access not

Policies alone are not enough: each table also needs the matching permission grant for signed-in members. Missing it produces a permission error rather than an empty list.