Wrong-account URL gets you bounced

If you open an account address you don't belong to, the page redirects you home instead of rendering anything.

What it is

A middleware check that runs before any page or API route. It builds the set of org ids the signed-in user actually belongs to — their primary account plus any additional memberships — and compares it against the org the URL resolved to. A mismatch is refused: APIs get a 403 with a plain reason, page navigations get redirected to the apex with the impersonation cookie cleared on the way through.

Also called: cross-tenant block · typed another company's address · not a member of this tenant

See it
Wrong-account URL gets you bounced
Area
Platform & Admin
Group
Tenancy & isolation
System
Multi-Tenancy & Identity
Solves
3 named problems
01The user's membership set is assembled from publicMetadata.orgId plus any entries in publicMetadata.memberships.
02The subdomain-derived org id is compared against that set.
03Platform-side users are exempt because entering accounts is their job and it runs through the impersonation flow instead.
An animation: type another company's subdomain, hit enter, and the address bar snaps back to your own account's dashboard. Logic in src/middleware.ts; landing screen is the app shell. Sample data — no customer information appears here.
How it works
  1. 1The user's membership set is assembled from publicMetadata.orgId plus any entries in publicMetadata.memberships.
  2. 2The subdomain-derived org id is compared against that set.
  3. 3Platform-side users are exempt because entering accounts is their job and it runs through the impersonation flow instead.
  4. 4Users mid-onboarding (no org yet) are exempt so the onboarding and invite-accept flows can complete.
  5. 5The block is logged with the user, the subdomain and the membership list so a false positive is diagnosable.
  6. 6A page mismatch redirects to the apex root with ?as=clear, which the apex uses to route the user to their own account.
Why we built it

This is the page-level half of the fix described in serverAuth — the API half returns 401, and without a matching redirect the user would sit on a dead error screen with no way back. The middleware comment records the discovery in one sentence: a worker correctly invited to one builder 'ended up viewing [another builder's] $863K pipeline just by being on' that builder's subdomain. Clearing the impersonation cookie during the bounce matters too: a stale cookie is exactly how the wrong-account state persists after the redirect.

The problem
  • A valid session on the wrong account URL rendered that account's data.
  • A blocked API call with no page-level redirect left users stuck on an error screen.
  • A stale impersonation cookie could re-assert the wrong account after a bounce.
Sound familiar?
What you get
Guessing or mistyping another company's address does nothing.
The bounce lands you in your own account rather than on an error.
Every block is logged with enough context to tell a real block from a bug.

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 →