Stat Notes Help

1. Quick start

Pick the role that matches what you're doing right now. Each card is a 60-second orientation; the numbered sections below go deeper.

2. Roles

Every user in your workspace has exactly one of three roles. Roles are set by an admin on the admin page.

2.5 Managing users

Everything in this section lives on the admin page under User Management. Admin role required.

Adding users

There are three ways a user gets into your workspace, depending on how your tenant signs in:

• SSO with JIT provisioning (default when SSO is enabled). Your IdP assigns the Stat Notes app to a user, the user clicks "Sign in with SSO," and on first successful login we auto-create them as a stat_user. No admin action required.
• Pre-invite via SSO (new). If you want a user to start with a specific role — for example an admin who should not have to be manually promoted after their first login — use the Invite SSO user form on the admin page. Enter their email and the role you want; when they later sign in via SSO, the JIT provisioner matches their email and honors the pre-declared role. This form is only shown when SSO is enabled on your tenant.
• Password user (fallback). The Add user with password form creates a traditional username + password account. Use this only for legacy accounts or when SSO isn't available. New workspaces should prefer SSO or magic-link.

Reading the user list

Each row shows the username (an email address), a role badge, an auth-method badge, and the last sign-in time. The auth-method badge tells you how this user signs in:

• SSO — purple. Provisioned by SSO. No password on file.
• Password — grey. Legacy password account.
• SSO + Password — blue. Has both a password on file and an SSO identity.
• Magic-link — green. No password, no SSO, but they've signed in via email magic-link at least once.
• Invited — amber. Pre-provisioned but has never signed in yet.

Editing a user

Click Edit to change a user's role. Usernames are immutable — to rename, delete and recreate. For SSO-only users, the password input is hidden and replaced with a note; there's nothing useful to change there.

Disable vs permanently delete

Three different levers from most-reversible to most-destructive:

• Disable — the safest option. The user keeps their row, their audit history, their shortcuts, and their data — but they can't sign in. Any currently active session is killed on the next request (the middleware reloads the user from the database and rejects disabled accounts). Use this for employees on leave, offboarding in progress, or anyone you might reactivate.
• Force sign-out — kills all active sessions for that user immediately, but they can sign in again right away. Use this when you suspect a session is compromised, or when you want to force someone to pick up new role or group membership on their next sign-in.
• Permanently delete — removes the user row. Irreversible. Audit log entries that reference the user stay intact (the foreign key goes null). Note: if your SSO domain allowlist still includes the user's email domain, SSO will happily re-create them as a stat_user on their next sign-in. The delete confirmation warns you about this. If that's not what you want, disable them instead, or narrow the allowlist first.

Pre-inviting the first admin for a new workspace

If you're standing up a new tenant for a team that will use SSO, the cleanest flow is: (1) configure SSO and run a successful Test, (2) enable SSO, (3) pre-invite the designated workspace admin with the admin role via the Invite SSO user form, (4) ask them to go to your tenant URL and click "Sign in with SSO." They'll land on the admin page with full rights on the first click — no dance of "log in as stat_user, email Colin to promote me."

3. Writing and sending notes

The Input page is the main working surface for the stats desk. The left column is your editor and send controls; the right column shows two live previews.

The editor

• Big editor — a contenteditable area sized for fast typing. Paste from anywhere; HTML formatting is automatically cleaned up to keep only useful structure.
• Bold / italic via the toolbar or Ctrl+B / Ctrl+I (Cmd+B / Cmd+I on macOS).
• Text color via the color picker in the toolbar.
• Character and line count updates live in the toolbar.

The two previews

• About to send — what will appear on the monitor the moment you press Send. Renders with your saved display settings (font, size, colors, bounding box).
• On air — what is currently showing on the monitor right now. Use Load into editor to pull the live note back into the editor for a quick fix-and-resend.

Sending

• Click Send Note or press Ctrl+Enter (Cmd+Enter on macOS).
• The note is sanitized on the server (scripts, event handlers, and javascript: URLs are stripped — you can't accidentally push executable HTML to a monitor).
• Every monitor using a valid display token picks up the new note on its next poll, typically within ~1.5 seconds.
• Every send is recorded to the audit log with your user ID, IP, and the note contents.

Clearing the note

The Clear button empties the local editor only. To blank the on-air monitor, send an empty note or use an empty shortcut. The current-note endpoint is updated immediately and every connected monitor goes dark within ~1.5 seconds.

History and resend

Every sent note is stored in the history. Go to History in the top nav to search, filter, and resend any prior note with one click.

4. Shortcuts and hotkeys

Shortcuts are reusable notes bound to a keyboard trigger. They're per-user, not workspace-wide — every operator builds their own kit.

Creating a shortcut

1. Open Shortcuts in the top nav.
2. Enter a Name (e.g., "Home lineup", "Commercial break").
3. Enter the Content — plain text or light HTML.
4. Pick an optional Hotkey.
5. Click Add.

Supported hotkeys

Exactly 32 slots are available per user:

• F1–F12 — function keys
• Ctrl+0 through Ctrl+9 (also Cmd+0–9 on macOS)
• Alt+0 through Alt+9 (also Option+0–9 on macOS)

Triggering a shortcut

Pressing the hotkey on the Input page loads the shortcut's content into the editor — it does not auto-send. You still control the moment of Send. This prevents accidents like a thumb resting on F5.

Editing, reordering, deleting

• Drag any shortcut row in the Shortcuts page to reorder. The drawer on the Input page follows the same order.
• Edit opens a modal where you can change the name, content, and hotkey.
• Delete removes the shortcut permanently. Deleted shortcuts are not in history; save a copy first if you want to keep the text.

5. Display tokens and talent monitors

This is the section most customers get wrong on day one. Read it carefully.

What a display token is

A display token is a signed, per-monitor credential that authorizes /output.html. It's the reason you don't have to log anyone into a talent monitor — the monitor hardware is usually a set TV with no keyboard, and an operator cannot realistically type a password mid-broadcast. Instead, you bake the token into the monitor's URL once at setup and leave it running.

Creating a token

1. Sign in as an admin and go to Admin.
2. Scroll to the Display Tokens card.
3. Give it a descriptive name — something like "Main monitor - Truck 1" or "Studio B talent". This is just for your own bookkeeping.
4. (Optional) Enter a CIDR allowlist. See below.
5. Click Create.

Note: display tokens created before encrypted storage was rolled out cannot be re-viewed. If Show URL reports that the token is not recoverable, revoke it and create a new one.

Opening the monitor

1. Paste the full URL into the monitor's browser. It looks like:

2. Press F11 (or Control+Command+F on macOS) to go full-screen.
3. Leave the browser tab open. The monitor polls for new notes every ~1.5 seconds, so a sent note appears almost immediately.

CIDR allowlist (lock a token to an IP range)

A display token can be locked to a specific public IP or CIDR range. Even if the URL leaks on Twitter, a request from any other network is rejected at the middleware layer before the note data is ever read.

Examples:

The first locks the token to exactly one public IP (a single broadcast truck on a fixed LTE SIM). The second allows two /24 ranges (two venues). Leave the allowlist empty if you don't care — the token is still unguessable — but the CIDR lock is a meaningful second layer.

Revoking a token

Click Revoke on any token in the Display Tokens card. Revocation is immediate: the next poll (within ~1.5 seconds) from any monitor using that token fails and the monitor shows the built-in "Display token required" help page. There is no undo — to bring the monitor back, create a new token and paste the new URL.

Output visibility: token_required vs public

At the top of the Display Tokens card is a checkbox:

• Require a display token (default, recommended) — output_visibility = token_required. Any request to /output.html without a valid token is rejected. This is what you want 99% of the time.
• Unchecked — output_visibility = public. The output page is fully public. Anyone who guesses the URL sees the current note. Use this only for public venues where the note is already on a giant LED wall.

Troubleshooting: "the monitor shows a help page"

The friendly dark "Display token required" page appears when:

• No token is in the URL at all
• The token has been revoked
• The token belongs to a different workspace
• The token is CIDR-locked and the monitor is on the wrong network

Fix: create a fresh token on the admin page, copy the new URL, paste it into the monitor's browser. See also section 11.

6. Single Sign-On

Stat Notes supports both OIDC and SAML 2.0 for enterprise identity providers. SSO is per-tenant and self-serve — you configure it yourself on the admin page, with no back-and-forth email ping-pong.

OIDC vs SAML — which should you pick?

Use OIDC if your identity provider is modern: Okta (OIDC app), Microsoft Entra ID, Google Workspace, Auth0, Ping Identity, or anything labeled "OAuth 2.0 / OpenID Connect." OIDC is simpler to configure (three fields) and rotates keys automatically.

Use SAML if your IdP is older or your security team requires SAML specifically: ADFS, PingFederate, Shibboleth, or the "SAML 2.0" app type in Okta. SAML has more fields and requires you to paste a signing certificate, but it is still a fully supported first-class path.

Where to register Stat Notes with your IdP

Before you open the Stat Notes SSO page, tell your IdP admin the two values below. They are shown at the top of the SSO config page with a Copy button.

Replace your-slug with your actual workspace subdomain.

Configuring OIDC

On the SSO config page, pick the OIDC tab and fill in:

• Issuer URL — the HTTPS URL your IdP advertises. Okta: https://your-company.okta.com. Entra ID: https://login.microsoftonline.com/<tenant-id>/v2.0. Google Workspace: https://accounts.google.com. Must be HTTPS.
• Client ID — created when you register the Stat Notes app in your IdP. Paste the value as-is.
• Client Secret — shown once at app-creation time in your IdP console. Paste it here. It's stored AES-256-GCM encrypted and never echoed back.
• Allowed email domains — comma-separated, e.g. acme.com, acme.co.uk. Required. See below.
• Allow magic-link fallback for non-admins — leave checked during rollout so stat users can still sign in if SSO has a hiccup. Uncheck once SSO is proven stable.

Configuring SAML

On the SSO config page, pick the SAML tab. Open your IdP's metadata XML in a text editor — you will copy three values out of it.

• Metadata URL (optional) — if your IdP publishes a live metadata URL, paste it and the fields below auto-populate.
• IdP Entity ID — the entityID attribute on the root <EntityDescriptor> element.
• SSO Login URL — the Location attribute on the <SingleSignOnService> element with Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect".
• IdP signing certificate (PEM) — paste the full certificate including the -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- lines. This is the <X509Certificate> contents from the metadata, wrapped in PEM headers.
• Allowed email domains — same as OIDC. Required.

Why the email-domain allowlist is required

Even after your IdP successfully authenticates someone, Stat Notes independently checks the email domain against your allowlist. This defends against "a contractor with a personal Gmail happens to also be in the shared Okta tenant" accidents. It is a defense-in-depth layer and the field is required by design.

Test before enable

Click Save draft, then Test SSO. A popup opens, runs a full round-trip against your IdP using your own account, and reports success or a precise error. You cannot enable SSO for your team until at least one successful test round-trip has been recorded. Misconfigurations never ship to end users.

Once the test passes, click Enable SSO. Your team's login page will now offer an "Sign in with SSO" button.

Admin lockout rail

JIT provisioning

New SSO users are created on first successful sign-in as stat_user. Promote them to admin (or demote to viewer) from the user list on the admin page. Role claims from the IdP are ignored by design — privilege escalation by tampering with SAML/OIDC attributes is impossible.

SSO troubleshooting

• Test fails with an IdP error — almost always wrong Client ID, wrong Client Secret, wrong Issuer URL, or the callback URL is not registered with the IdP. Copy the callback URL from the top of the SSO page and paste it into the IdP app config exactly as shown.
• Test fails with "domain blocked" — the email address coming back from the IdP is not in your Allowed Domains list. Either add the domain, or fix the user's primary email in the IdP.
• SAML: "signature invalid" — the PEM block is wrong or truncated. Re-download the IdP metadata, recopy the X509Certificate, and wrap it in PEM headers.
• OIDC: "nonce invalid" — usually clock skew > 60 seconds. Sync the origin server's clock (NTP) or contact support.

7. Magic-link authentication

Magic-link is the default login path for new tenants and the permanent fallback for admins. No passwords, nothing to phish, nothing to rotate.

How it works

1. On the login page, enter your email.
2. You receive an email with a sign-in link.
3. Click the link in your email client. A confirmation page opens in your browser.
4. Click Confirm sign in. You are now signed in.

Why the two-step scanner-safe flow

Corporate email systems often "pre-fetch" every link in inbound mail to scan it for malware. Without protection, that pre-fetch would consume your magic link before you ever saw it. The two-step confirmation page defeats this: the link itself only loads a static page, and only your deliberate click on Confirm sign in actually burns the token.

6-digit code fallback

If your mail client mangles the link (breaks it across lines, rewrites it, or strips the query string), request a 6-digit code instead. Enter the code at /auth/enter-code and you'll be signed in. Same token, different transport.

Expiration

Magic links and codes expire 10 minutes after issue. If yours has expired, request a new one — there is no penalty for requesting many.

For admins: the always-available path

Even if SSO is live and password login is disabled for stat users, admins can always request a magic link and sign in. This is the lockout-recovery rail described in section 6.

8. Billing

• Price: $150 / year per workspace, annual auto-renewal.
• Trial: 14 days free, no credit card required. Full access during the trial.
• Activate: go to /activate (or click the activate pill in the top-right during trial) to enter card details. Billing is powered by Stripe Checkout.
• Manage subscription: on the admin page, the Billing card has a Manage subscription button that opens the Stripe customer portal. From there you can update your card, view invoices, download receipts, and cancel.
• Cancellation: you can cancel anytime. You keep access through the end of the paid period. No pro-rated refunds.
• Receipts: Stripe emails a receipt automatically after every charge.
• Trial expiry: if your trial ends without a subscription, the workspace enters a soft-locked state. Talent monitors keep running (so a live broadcast is never interrupted), but sending new notes returns a 402. Activate to restore full access.

9. Audit log

Every security-relevant action in your workspace is recorded to an append-only audit log that admins can view on the admin page.

What gets logged

• Every login attempt (success and failure, with reason)
• Every magic link issued and every SSO round-trip
• Every note sent or cleared, with the note contents
• Every display-token create, edit, and revoke
• Every user invite, role change, and deletion
• Every SSO configuration change
• Every billing event and Stripe webhook

Fields recorded

Each audit entry includes the actor (user ID or system), event name, tenant ID, IP address, user agent, timestamp, and a JSON metadata blob specific to the event.

Who can see it

Only admins of your workspace, and only for your workspace. There is no cross-tenant view — by design, the query layer cannot name another tenant.

Export

Full audit log exports (JSON or CSV) are available on request — email [email protected] with your tenant slug.

10. Security notes

Short version: TLS 1.3 end-to-end, AES-256-GCM at rest for every secret (OIDC client secrets, SAML certs, SMTP creds), row-level tenant isolation enforced by middleware, append-only audit logging, no analytics, no third-party trackers.

Full public write-up for procurement teams: https://statnotes.app/security.html.

A Data Processing Agreement (DPA), SIG Lite responses, and custom security questionnaires are available on request. Email [email protected] with your tenant slug.

11. Troubleshooting

12. Getting help

Email: [email protected]

Response target: within 48 hours during business days; faster during active broadcasts — tell us the show time and we'll be watching.

Please include your tenant slug (the part before .statnotes.app) so we can find your workspace without a back-and-forth.

For security questions, DPAs, or vulnerability reports, the same email address works — just say "security" in the subject line.