Sharing a book with an accountant

ShippedWorks today.

Access is granted per project or per book with one of three roles, invitations are sent by email and expire in seven days — and the role you give someone is the scope their tools get.

The shape of it

An org is your workspace. Inside it are projects, and inside those are books. You share a project — which covers every book in it — or a single book, which is the narrower case.

Three roles

RoleLedgerCan manage sharing and keys
ownerread + writeyes
accountantread + writeno
clientread onlyno

This is not a label on a page. The role decides the scope of the token minted for the ledger every time that person’s tools call the API: owner and accountant get readwrite, client gets read. A client with a plugin connected can query, report and open the browser ledger, and every write they attempt is refused by the book itself.

Separately, org membership makes someone a workspace collaborator with read and write access across the whole org — but not the owner-only management powers. Only the org owner, or a grant owner on that specific project or book, can invite people, issue or revoke keys, create books, or rename, delete, suspend and resume them. Everyone else attempting one of those gets 403.

Inviting someone

From the collaborators page: an email address, a target (project or book), and a role. They get a link, sign in or sign up, and the grant is created on acceptance.

An invitation expires after seven days. Re-inviting the same address supersedes the old invitation and carries the new role — which is also the resend path when the first email did not arrive, with a sixty-second gap between two invitations to the same person for the same target.

There is a daily ceiling on invitations, tighter for accounts less than a week old. It exists because signup is open and nothing verifies an email address, so without it the invite endpoint is a machine for sending attacker-written text from our domain. Both limits are far above what someone sharing books with their accountant will ever reach.

Changing your mind

A grant’s role can be changed in place, and a grant can be revoked. Revocation is real rather than cosmetic: keys are checked against the database on every request, so the next call after a revoke fails rather than running until a cached token expires.

Seats, and a straight answer about them

The plans on pricing name a number of books and a number of seats. Nothing in the control plane counts either today. There is no seat ledger, no check on book creation, and no code path that refuses an invitation because a plan is full. The numbers describe the plans as sold; they are not currently enforced, and you should hear that here rather than discover it in either direction later.

What there is not

No teams or groups. Access is granted to a person, on a project or a book. There is no group you can add five people to.

No per-collaborator permissions beyond the three roles. You cannot grant someone one account, one date range, or read on the reports and nothing else.

No SSO and no two-factor authentication. Google or email and password, for everyone.

No activity feed for collaborators. Who changed the ledger is in the git history, which names the commit and shows the diff. There is no separate notification when your accountant touches something.

No scheduled or emailed reports to send them either. They open the book, or you generate a workbook and send it.

Something here wrong or missing? Put it on the board — it is public, and the reply is in the thread.