Account verification contract

Purpose: ask the new user to confirm their Built account. API implementation: App\Mail\confirm. Baseline: resources/views/emails/users/confirm.blade.php. Referenced from signup/signupV2, verification resend and related email-controller paths. This is the custom API confirmation flow, not an assumed second framework-generated email.

Suggested subject: Verify your account. This preserves the current subject.

Suggested preheader: Complete your signup on Built by confirming your account.

Portable placeholder contract

Token	Existing Laravel source / derivation	Requirement
{{logo_url}}	Existing Built app_name PNG	Optional deployment override; concrete project HTTPS logo is the default
{{preheader}}	Suggested fixed copy above	Required escaped text
{{first_name}}	$user->first_name	Required existing greeting value; escape as text and preserve long names
{{verification_url}}	Current Blade expression config('app.url') + '/verifyaccount/' + encrypt($user->id)	Required complete trusted URL; use the existing expression/server-generated value without changing identifier semantics

No expiry duration is stated in the existing confirmation email. The draft does not add an expiry, a timestamp, a one-use assertion or an approval claim. Account confirmation remains separate from signup welcome and password recovery.

States and integration

The two populated states are a normal request and a long fictional first name/link. They are layout checks, not different server workflows. No expired/invalid email type has been invented. All demo links are local and inert.

The action label stays Verify your account. The added visible fallback URL repeats the same verification_url; it is not another action or a new backend field. The current view derives the URL directly rather than receiving a data key named verification_url. Translate the portable token to that existing Blade expression or to a trusted value computed in the existing integration layer. Do not interpret a user identifier as a token or encrypt it in a new browser-side script.

ready/verification.txt and matching populated .txt files contain the greeting, confirmation instruction and URL. Use escaped Blade text/attributes and separately validated trusted application URLs. The public logo defaults and optional HTTPS/CID override are documented in integration-notes.html. Both native light/dark CSS and responsive layouts remain email-only HTML/CSS with no preview script.

Framework Registered/verification notifications and older mails.verifyaccount are unresolved/legacy paths in the catalog. Do not create duplicate live verification sends during integration.