Customers are never asked to log in

Every customer-facing surface — invoices, portals, crew links, booking pages, policy pages, lead forms — is explicitly exempt from the login wall, with an unguessable token as the authentication instead.

What it is

A long, heavily commented allowlist at the top of the middleware. Each entry says which audience it serves and what authenticates it in place of a session: an unguessable token in the URL, a signed parameter, a shared header secret, a per-provider source key, or IP rate limiting. Anything not listed goes behind the login wall by default.

Also called: customer portal login wall · no account needed · public link · sign in screen for customers

See it
Customers are never asked to log in
Prepared for
Ivy Brubaker
1140 Ridge Line Rd · Fair Play
Shell package$28,080
Concrete & site$8,152
Doors & windows$5,435
Trim & finish$3,623
Total
$45,290
Signature
A customer tapping an invoice link on a phone and landing straight on the branded invoice, with no login step. Allowlist in src/middleware.ts; page at src/app/invoice. Sample data — no customer information appears here.
How it works
  1. 1The allowlist is matched before any authentication runs.
  2. 2Token routes — invoices, client portal, crew portal, subcontractor portal and hub, supplier agreements, booking — carry their own auth in the handler.
  3. 3Machine callers — scheduled jobs, webhooks, terminal tooling — authenticate with a shared secret and fail closed on a missing or wrong value.
  4. 4Public forms authenticate with a source key plus rate limiting.
  5. 5Crawler files, marketing pages and the tenant policy pages are public by necessity.
  6. 6Hidden booking links additionally get a no-index header even on a public route.
Why we built it

This list is a scar tissue map, and it says so. On the invoice viewer, bug L2B-CX8V8B: without the entry 'Clerk auth-walled paying customers: they clicked an invoice inside their portal and landed on a sign-in screen they could never pass. Customers are NEVER asked to log in.' On the support directory: 'a customer who can't sign in is exactly the person who needs the support directory, and auth-walling it is the failure this list exists to stop.' On the crew portal: 'Missing this list is the single most repeated bug in this file — a token route that never reaches its handler because Clerk intercepted it first, and the symptom is a redirect loop, not a 401.' And on the terminal tooling: behind the wall the route 'returned the sign-in HTML with a 200, so the resolve script parsed {} and cheerfully reported success while the ticket stayed open.'

The problem
  • Paying customers hitting a sign-in wall they could never pass.
  • Token-authenticated links intercepted before reaching their handler, producing redirect loops.
  • Machine callers receiving a sign-in page with a 200 status and reporting false success.
Sound familiar?
What you get
Customers open estimates, invoices and portals with one tap, no account.
Crew and subcontractor links work on a phone in the field.
Each exemption is documented with what authenticates it instead.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →