Email Verification

Registration flow

The signup form posts to /api/auth/register with a fresh Turnstile token (action signup). The server stores expiring pending data and a Better Auth password hash in verification, then sends the email. No formal user, session or credits exist yet. A rejected or failed send rolls back this pending attempt; the same email can register again.

Opening the link within 24 hours creates the verified user, password account and 20-credit ledger grant in one transaction and consumes the pending record. The user then signs in. Verification does not automatically sign them in.

Resending and existing accounts

The /check-email page calls POST /api/auth/resend-verification. Pending registrations use a separate HttpOnly cookie, not a login session. Resending rotates the link and requires a one-minute interval. If the cookie is missing or registration expires, return to signup.

Old unverified users remain intact. Entering the correct password on the login page requests a verification email without creating a session. Previously issued legacy links remain supported. Direct Better Auth email signup is disabled in lib/auth.ts; changing requireEmailVerification alone does not change the pending flow. Google OAuth retains its existing flow.

Successful links can be reopened until their original expiry. Only a hash-keyed completion receipt and user ID remain; pending identity and password hash are removed, and credits are never granted again.