Concepts

Identity & keys

There are two kinds of people in a Notr deployment: you (the developer) and your users. Notr authenticates you; your users stay yours.

Developer accounts are the tenant

Your console account owns everything: every note and every service key created under it. Requests are always scoped to one account — a key can never see another account's notes, and notes never leak across tenants.

Registration is closed. This deployment runs in single-account mode: the only sign-in accepted is the admin account defined by ADMIN_EMAIL / ADMIN_PASSWORD in the server environment, seeded automatically on boot. Changing the password in the environment re-syncs it on the next restart.

Service keys

A service key (prefix notr_) identifies your application's backend. Generate and revoke them in Console → API keys; the full key is shown once at creation.

Send it as the x-api-key header on REST calls:

curl https://notr.example/api/notes \
  -H "x-api-key: notr_••••••••"

Property	Value
Header	`x-api-key`
Rate limit	1,000 requests per minute per key
Revocation	Immediate, from the console
Scope	Full access to the owning account's notes

Keys are backend secrets. Anyone holding a key can read, modify, and delete every note in your account. Keep it in your server environment — never in browser bundles, mobile apps, or client-side code of any kind.

Console sessions

The dashboard itself authenticates with a session cookie (email + password). Sessions and service keys resolve to the same account, so a note created with a key shows up in your console and vice versa.

Collaboration credentials

WebSocket connections to /collab authenticate during the handshake with a token:

Token	Who it's for
`"session"`	Browsers with a console session — the cookie does the real work. This is the editor's default.
a service key	Server-side clients (agents, importers, migration scripts) connecting from your backend.

Either way, the connection is rejected unless the credential's account owns the note being opened.

Your end-users

Notr has no opinion about your users — no user table for them, no signup flow, no permissions model between them. Today, identity shown to collaborators (the name on a caret) is whatever you pass to the editor's user prop.

On the roadmap: consumer-signed collaboration tokens — your backend signs a short-lived token asserting "this is user X, allowed to edit note Y", and browsers connect with that instead of any shared secret. This keeps your application the source of truth for your users while letting them connect to Notr directly.