Documentation

Appearance

Beta invitations: operator procedure ​

Use the backend invitation operator runbook for the detailed transaction and verification steps. The beta access guide explains the product journey. This procedure does not send an email by itself.

Normal distribution ​

An authenticated super administrator generates a code in the admin, copies the plaintext shown once, and privately distributes it. Codes have 96 bits of random entropy, formatted as SNAG- followed by six four-character groups. PostgreSQL stores the SHA-256 digest and a short hint, not recoverable plaintext.

On a recipient-aware deployment, the email is normalized and hashed for tracking/regeneration; its display hint is masked. Generating a replacement invalidates earlier unused invitations for that recipient, not existing admitted accounts. The verified identity redeeming the code may differ from its intended recipient, including Apple relay. This is a single-account invitation, not an email-login code or a password-reset token.

Check deployment before generating ​

Read the actual API database schema and the live beta status. Do not assume migration 0054 is active merely because it exists in Git. The base table has no email_hash or email_hint, so it cannot track a recipient or regenerate by email. Stop the recipient-aware operation and roll it back if those fields are absent; do not apply a migration as a side effect of generating a code.

When expressly authorized, an operator may issue a standalone single-use code against that base schema. This does not bind it to the supplied address and does not create the admin actor audit record. Communicate that limitation. Keep a non-sensitive operations note, and do not impersonate an administrator in SQL. Account deletion is never necessary to issue a code for an existing address. An existing account should sign in; do not recreate it to bypass an error.

Verify without using the invitation ​

  1. Confirm the inserted row is unused, enabled and unexpired, by its row ID.
  2. Confirm GET /api/auth/beta/status reports the gate enabled. With the gate off, validation accepts any input and is not proof of invitation validity.
  3. Submit the code in the JSON body of POST /api/auth/beta/validate, never in a URL or shared log. Expect HTTP 200 with valid: true.
  4. Confirm it is still available in PostgreSQL. Do not call registration or redemption to test the recipient's actual code.
  5. Return it only through the authorized private delivery channel. Do not place the code, its digest, full recipient address or credentials in a PR, issue, screenshot, support log or documentation.

A verification timeout after commit does not mean generation failed. Check the specific row before retrying. If plaintext is lost, use an authorized replacement procedure; hashes cannot recover it. Regeneration and revocation do not revoke admission already granted to an account.

Evidence and limits ​

On 4 November 2026 the API database used the base table without recipient metadata. One invitation was created through the operator fallback and validated without consumption. No account or collection was changed, no automatic email was sent, and no migration or service restart was performed. This observation does not establish that admin email tracking currently works in production.

See the tracking entry.