Partner Access

By default, Vulcan apps are accessible to anyone with an @shipveho.com account. Some apps need to be opened to people outside Veho — DSP admins, vendors, contractors — without giving them access to Vulcan IDE or to every other app on the platform.

Partner Access lets you do that on a per-app basis.

---

Two ways in

Pick based on who's actually signing in:

	Passkey enrollment	Device share passcode
Best for	A specific person on their own laptop / phone (DSP admin, contractor, vendor employee)	A shared device — warehouse TV, kiosk, breakroom monitor — used by many people
What the operator types	Nothing — biometric (Touch ID / Windows Hello / phone fingerprint)	A 6-digit passcode, once per device
One credential maps to	One person, one identity	One app, many devices
Provisioning	Owner generates a single-use invite URL per partner email	Owner mints one passcode, distributes URL + code separately to each device operator
Session lifetime	90 days	30 days
Loss recovery	Owner regenerates invite URL for that partner	Owner rotates the passcode (re-pairs new devices; existing TVs keep working)

Both flows live on the same Access button in the App Builder toolbar. You can use them together — passkeys for a few named partners + a passcode for the warehouse TVs they walk past.

---

When you'd use this

• Passkey: building an app for a DSP partner to manage their own routes, letting an external vendor view a dashboard you built for them, sharing a status page with a specific customer account.
• Passcode: a warehouse dispatch board that 10 TVs display on a loop, a breakroom kiosk anyone can walk up to, a customer-facing screen in a vendor's facility.

If the people you want to share with all have @shipveho.com accounts, you don't need either — they already have access. Partner Access is specifically for non-@shipveho.com users and for shared devices that don't belong to one person.

---

What partners CAN do

• Sign in to the specific app(s) you've invited them to
• Use any feature inside those apps
• Stay signed in for 90 days at a time

What partners CAN'T do

• Access the Vulcan IDE
• Access any other Vulcan app they weren't explicitly invited to
• Browse a project hub or see what other apps exist
• Sign up themselves — every partner has to be added by an app owner

---

Adding a partner

1. Open your app in the App Builder
2. Click the Access button in the top toolbar (next to the Team button)
3. Type the partner's email and click Add
   • Must be a non-@shipveho.com email
   • The email doesn't have to be a Google account, Microsoft account, or anything specific — passkey enrollment uses the partner's device biometric, not an external identity provider
4. Once they're in the allowlist, click Generate invite URL
5. The URL appears in a box with a Copy button — send it to your partner via Slack, email, or however you normally communicate

What the partner does

1. Clicks the invite URL within 24 hours
2. The page asks them to register a passkey using their device's biometric (Touch ID, Windows Hello, phone fingerprint, etc.)
3. They confirm with their biometric
4. They're signed in and can access your app's URL

After enrollment, they sign in with the same biometric — no URL needed for subsequent logins.

---

Important rules

Invite URLs are single-use

Each URL works for exactly one passkey enrollment. After the partner clicks it and completes (or starts) enrollment, the URL is dead. If something goes wrong during enrollment (closed tab, cancelled biometric, browser quirk), generate a fresh URL and try again.

Invite URLs expire in 24 hours

If the partner doesn't click within 24 hours, generate a new one.

Treat the URL as a secret

The signed URL is the credential for the initial sign-in. Anyone who has the URL before the partner uses it can claim the session for that email. Send it through a channel you trust (private Slack DM, encrypted email) — not a shared channel or a public ticket.

After the partner completes passkey enrollment, the URL is dead and can't be reused, so leak risk only exists in the window between you generating the URL and the partner clicking it.

Each partner enrolls one or more passkeys

A partner can register up to 5 passkeys — useful if they want to sign in from both their phone and laptop. Each device shows up in the Enrolled passkeys section of the Access page with a last-used timestamp.

---

Re-authentication

A partner session lasts 90 days. When it expires:

1. Partner visits the app URL again
2. They're shown a sign-in chooser ("Sign in with Google" or "Sign in with passkey")
3. They pick passkey, biometric, done — no owner involvement

If they lose their device or their passkey:

• They ping the app owner (you)
• You regenerate the invite URL
• They re-enroll on their new device

---

Removing a partner

In the Access page:

• Remove from allowlist — partner immediately loses access to this specific app on their next request. Their session might still be in their browser for a few seconds but the gateway returns 403 within ~30 seconds.
• Revoke a specific passkey — kills sign-in for that one device. They'd need a new invite URL to re-enroll on that device.

Removing the email entirely is the nuclear option — they're out for good unless you add them back.

---

Preview AND production

When you add a partner to your project's allowlist, they get access to both your preview and production deploys (whichever exist). The allowlist applies symmetrically. If you only have a preview deploy and you go on to deploy to production later, the production deploy inherits the same allowlist automatically.

---

Browser compatibility

Passkeys work on:

• macOS 13+ (Safari, Chrome, Firefox) using Touch ID or your password manager
• iOS 16+ (Safari) using Face ID / Touch ID
• Windows 11 (any modern browser) using Windows Hello
• Android 9+ (Chrome) using device biometric

If you (or your partner) have trouble enrolling or signing in:

• Some password-manager extensions (1Password, Bitwarden) can intercept the passkey prompt in regular browsing mode and show their own UI instead. Try an incognito/private window, or disable the extension on vulcan.shipveho.com.
• Safari with iCloud Keychain is the most reliable combination on Apple devices.
• Chrome Password Manager also works but can be confused by multiple Chrome profiles or sync delays.

---

What this is NOT

• Not a way to give partners @shipveho.com access. Use Workspace for that.
• Not a way to restrict which @shipveho.com users can see your app. Internal users always have access.
• Not a public sign-up flow. Every partner has to be explicitly added by you.

---

---

Device share passcode (shared displays)

For warehouse TVs, kiosks, and other browser-only devices that can't enroll a passkey, mint a single 6-digit passcode that any device can use to sign in. Same Access page, different section.

Setting it up

1. Open the Access page for your app (the Access button in the App Builder toolbar).
2. Scroll to the Device share passcode section.
3. Click Mint passcode.
4. The page shows the URL and the 6-digit passcode in separate copy-to-clipboard rows. Copy both now — the passcode is shown only once and is unrecoverable after the page is closed or refreshed. Both production and preview URLs are listed; the same passcode unlocks either.
5. Share the URL and the passcode with whoever is setting up the devices. Best practice: send them through different channels (e.g., URL via Slack, passcode verbally or written on the warehouse whiteboard) so a single leak doesn't grant access.

What the operator does on each device

1. Visit the URL on the device. The page redirects to a sign-in form titled Enter passcode.
2. Type the 6-digit code.
3. The device is signed in. The form sets a cookie scoped to that specific app path; the operator can close and reopen the browser and the app loads without re-entering the code for 30 days.

The cookie is HttpOnly + Secure + SameSite=Lax and the path is restricted to the specific /<user>/<app>/ (or /preview/<user>/<app>/) — so even if a device gets a passcode for App A, that cookie can't reach App B.

Rotation

If the passcode leaks or you just want to rotate periodically:

1. Open the Access page → Device share passcode section → click Rotate passcode.
2. A new code is minted. The old code stops working immediately for fresh devices.
3. Already-paired devices keep working until their 30-day cookie expires — they don't need to be re-paired with the new code.

This means rotation invalidates the distribution channel (the URL + passcode you shared) without taking down the warehouse mid-shift.

To force every device off (e.g., suspected device theft), click Revoke, then Mint a fresh passcode. After revoke, no cookie is honored regardless of when it was issued.

Security tradeoffs

Read these before pointing a passcode at anything sensitive:

• The passcode is the credential. Anyone with the 6 digits and the URL can sign in. Treat the passcode like a password.
• 6 digits is brute-force-safe under rate limiting (10 attempts per IP per hour). At that throttle, exhausting all 1,000,000 combinations would take ~11 years.
• Cookie path is the primary defense — a passcode for App A grants access to App A only, even from the same device.
• Acceptable for warehouse-floor-visible content. Apps showing PII, financial data, or anything that a passer-by in the warehouse shouldn't see should NOT use share passcodes — keep partner-access passkey enrollment for those.
• The plaintext is never stored on the server — only the SHA-256 hash. If you lose the code before paring a device, rotation is your only recovery path.

---

Trouble?

If a partner says the invite URL doesn't work:

• "Invite link already used" — they (or someone) already clicked it. Generate a new one.
• "Invite link expired" — over 24 hours since generation. Generate a new one.
• "Access revoked" — the email isn't in the allowlist anymore (you removed it, or never added it). Add it and generate a fresh URL.
• "Invalid invite link" — the URL signature didn't verify. Usually means the URL was mangled in transit (line-wrap from a chat client, character lost in copy/paste). Generate a new one and send it through a channel that won't break long URLs.

If their passkey ceremony hangs at "Confirm with your device biometric":

• The OS prompt may have failed to appear. Refresh, try again.
• The prompt may be behind another window. Bring the tab to the front.
• A password-manager extension may be intercepting. Try incognito.
• After 60 seconds, you'll get a DOMException: The operation either timed out or was not allowed. Try again.

If a device share passcode isn't working:

• "Incorrect passcode" — re-check the 6 digits with the person who minted it. If you've rotated since the operator received the code, they have the old one — share the new one.
• "No passcode is configured for this app" — the passcode was revoked. Mint a new one.
• "Too many attempts. Try again in an hour." — that IP has burned through its 10-attempt budget. Wait an hour or try from a different network.
• The page loops between the entry form and the app URL — the cookie didn't stick. Most likely the browser is in incognito with cookies disabled, or a corporate proxy is stripping Set-Cookie. Try a regular (non-incognito) window first to confirm.
• A previously-paired TV stopped working after rotation — that's not how rotation works. Rotation keeps existing cookies valid; you must have hit Revoke instead. Mint a fresh code and re-pair each TV.