Internal Probe

Reference demo evaluation guide

Use this page as the product-probe script for the Lamba customer surface. The goal is to see which API contracts, UX decisions, and end-to-end flows still feel incomplete before external rollout. Notes stay outside the app; this page only makes the scenarios and surfaces explicit.

Auth host

https://test.id.uselamba.com

API host

https://test.api.uselamba.com

Fixture binding

f9d96d5d-502b-42a6-9a10-65827960c043f05165e2-1e21-45ac-b2e4-972dc3353d05test

Hosted callback

https://sandbox.demo.uselamba.com/api/auth/hosted/callback

Hosted OIDC is enabled for this run.

Companion tools

Keep the webhook companion app running when you reach the delivery scenarios.

This emits one synthetic webhook envelope from the reference demo so you can inspect the hosted sink contract without waiting on upstream product events.

Webhook sinkhttps://sandbox.webhook.demo.uselamba.com/api/webhooks/lamba
Notes captureChat or spreadsheet outside the demo

Stable fixture inputs

  • Pinned sandbox customer hosts: one auth host and one API host for all probe runs.
  • One workspace id, project id, and environment binding kept stable across a full evaluation pass.
  • One configured webhook sink URL that points to the local WebhookSink companion app.

Mutable outputs

  • Invitations, applications, domains, webhook endpoints, webhook deliveries, and any profile or verification writes.
  • Hosted OIDC redirect URIs that may need temporary entries while you iterate locally.

Reset checklist

  1. Delete throwaway applications, domains, invitations, and webhook endpoints created only for probing.
  2. Reset or clear WebhookSink event history when a fresh delivery pass matters more than long-lived logs.
  3. Keep one bounded sandbox workspace/project for this demo so cleanup stays local and visible.

Test personas

  • Fixture admin: existing project admin account used for admin/runtime setup flows.
  • Fixture member: non-admin or basic project member used for self-service and authorization checks.
  • Fresh invitee: throwaway email address used for invitation, register, and verification experiments.
Setup and fixture

Confirm the reference demo is pinned to the intended workspace, project, environment, and webhook sink before evaluating product gaps.

ScenarioOpen surface

Validate the pinned fixture and redirect foundation

Check that the demo is bound to one sandbox workspace/project fixture and that redirect URIs are ready before running auth or admin flows.

Surfaces

  • Demo setup page: /setup
  • Local route handlers: /api/auth/hosted/start and /api/auth/hosted/callback
  • Customer auth host (id.*): /.well-known/openid-configuration and /connect/authorize

Required setup

  • LAMBA_CUSTOMER_AUTH_BASE_URL and LAMBA_CUSTOMER_API_BASE_URL point to the sandbox customer surface.
  • LAMBA_CUSTOMER_WORKSPACE_ID, LAMBA_CUSTOMER_PROJECT_ID, and LAMBA_CUSTOMER_ENV are pinned for the current fixture.
  • At least one redirect URI is registered for the environment you are testing.

Manual checks

  1. Open /setup and verify auth host, API host, workspace id, project id, and environment.
  2. Confirm the hosted redirect URI matches the currently running local demo origin.
  3. Use the page links to inspect Runtime Auth, Domains, and App Clients when a scenario depends on those surfaces.

Expected outcome

  • The setup page exposes a single coherent fixture instead of mixed workspace or project context.
  • Hosted OIDC can start without callback mismatch errors.
  • The page makes the app client and redirect preparation steps obvious before auth testing begins.
Authentication flows

Exercise the main customer auth entry points and confirm the demo preserves the public customer-surface contract end to end.

ScenarioOpen surface

Password sign-in and register upgrade into scoped session

Verify password login or registration returns a customer session and the demo immediately switches it into the pinned workspace/project context.

Surfaces

  • Local route handlers: /api/auth/login/password and /api/auth/register
  • Customer auth host (id.*): /v1/auth/login/password and /v1/auth/register
  • Customer auth host (id.*): /v1/sessions/switch-context
  • Customer API host (api.*): /v1/me/context

Required setup

  • Use a fixture user that already belongs to the pinned project for login, or a fresh throwaway email for register.
  • Workspace/project binding env vars are configured so the scoped-session upgrade path runs.

Manual checks

  1. From the home page, submit password login with an existing fixture member or register a fresh user.
  2. Allow the local route handler to persist the returned scoped access and refresh cookies.
  3. Land on /dashboard and inspect the active workspace, project, environment, membership, and session id.

Expected outcome

  • The user lands on /dashboard without sending binding headers directly to the customer hosts.
  • Active workspace and active project match the pinned fixture values.
  • Any auth or session mismatch is visible immediately on the dashboard context summary.
ScenarioOpen surface

Hosted OIDC redirect and callback handoff

Confirm discovery, authorization redirect, code exchange, and scoped-session handoff all behave like a production customer app.

Surfaces

  • Demo home page: /
  • Local route handlers: /api/auth/hosted/start and /api/auth/hosted/callback
  • Customer auth host (id.*): /.well-known/openid-configuration and /connect/authorize
  • OIDC token endpoint from discovery, followed by /v1/sessions/switch-context

Required setup

  • LAMBA_CUSTOMER_OIDC_CLIENT_ID is configured.
  • The current demo callback URI is allowlisted on the matching sandbox OIDC client.

Manual checks

  1. Use the hosted OIDC entry point from the landing page.
  2. Complete the hosted auth redirect and let the callback route exchange the code.
  3. After redirect back to /dashboard, compare the resulting context with the setup page fixture values.

Expected outcome

  • OIDC discovery and authorization start from the customer auth host, not platformapi.
  • The callback route stores scoped customer session cookies and routes to /dashboard.
  • Any missing app-client setup or callback mismatch is exposed as a concrete integration gap.
ScenarioOpen surface

Magic link, phone OTP, and email verification fallback paths

Probe secondary auth methods and verify whether the public customer contract and UX stay coherent outside the happy path.

Surfaces

  • Local route handlers: /api/auth/login/magic-link/*, /api/auth/login/phone/*, /api/auth/email/verify
  • Customer auth host (id.*): /v1/auth/login/magic-link/*, /v1/auth/login/phone/*, /v1/auth/email/verify

Required setup

  • Use sandbox responses that return development tokens or codes when available.
  • Use a fresh email or phone number when you need to validate verification prompts.

Manual checks

  1. Request a magic link without a token, then paste the returned sandbox token into the verify step.
  2. Request a phone OTP without a code, then paste the returned development code into the verify step.
  3. Run email verification with a known fixture or sandbox verification code.

Expected outcome

  • The demo makes the two-step alternate auth flows understandable without hidden backend knowledge.
  • Sandbox-only tokens or codes are clearly visible for evaluation.
  • Gaps in verification UX or problem-details messaging become easy to capture externally.
Context and self-service slices

Use the dashboard to verify whether the customer API already returns the runtime context and self-service data a real product app needs.

ScenarioOpen surface

Inspect context, memberships, security, and linked identities

Check if the self-service customer API surfaces are complete and readable enough to support a real product shell.

Surfaces

  • Dashboard page: /dashboard
  • Customer API host (api.*): /v1/me/context, /v1/me/memberships, /v1/me/authorization, /v1/me/security, /v1/me/linked-identities, /v1/me/profile

Required setup

  • Authenticate first so the dashboard can read the scoped customer session.

Manual checks

  1. Open /dashboard after a successful auth flow.
  2. Read the Active context and Host split summaries before inspecting the raw JSON blocks.
  3. Compare memberships, linked identities, and security posture with the scenario you just executed.

Expected outcome

  • The page answers basic product questions without forcing you into raw API inspection first.
  • Missing fields, ambiguous naming, or confusing JSON-only surfaces become obvious.
  • Role keys and effective permissions tell you whether runtime authorization is modelled clearly enough.
Admin/runtime contract

Exercise the admin slices that a project admin would use to wire customer-facing auth, domains, applications, and access control.

ScenarioOpen surface

Invitations, applications, domains, roles, and permissions

Confirm the customer admin contract exposes enough surface area for runtime setup and ongoing project administration.

Surfaces

  • Dashboard page: /dashboard
  • Local route handlers: /api/dashboard/invitations, /api/dashboard/applications, /api/dashboard/domains, /api/dashboard/domains/[domainId]/bindings
  • Customer API host (api.*): /v1/admin/invitations, /v1/admin/applications, /v1/admin/domains, /v1/admin/roles, /v1/admin/permissions, /v1/admin/authorization/catalog

Required setup

  • Authenticate as a fixture project admin.
  • Use throwaway emails, temporary redirect URIs, and sandbox domain values for write tests.

Manual checks

  1. Create a sample invitation with a throwaway email and verify it appears in the invitation history.
  2. Create an application client with redirect URIs that match your local demo origin.
  3. Add or update a sandbox domain and inspect its binding state against the active project and environment.
  4. Review roles, permissions, and authorization catalog output for naming, completeness, and discoverability.

Expected outcome

  • Core admin setup tasks are available without dropping to raw API tools.
  • The dashboard surfaces enough state to diagnose missing bindings, role catalog drift, or incomplete contract shapes.
  • Product gaps in admin write UX and API ergonomics are easy to spot during one pass.
Webhook delivery proof

Close the loop by creating a webhook endpoint from the demo and observing the resulting delivery in the local sink companion app.

ScenarioOpen surface

Create endpoint, trigger delivery, inspect sink

Verify the public webhook contract, delivery lifecycle, and sink inspection experience together instead of in isolation.

Surfaces

  • Dashboard page: /dashboard
  • Local route handler: /api/dashboard/webhooks/endpoints
  • Customer API host (api.*): /v1/admin/webhooks/endpoints, /v1/admin/webhooks/deliveries, /v1/admin/webhooks/events
  • Companion app: WebhookSink on /api/webhooks/lamba

Required setup

  • Start WebhookSink locally and keep its URL configured in LAMBA_CUSTOMER_WEBHOOK_SINK_URL.
  • Authenticate as a fixture project admin before creating the endpoint.

Manual checks

  1. Open /dashboard and create a webhook endpoint that points to the configured sink URL.
  2. Trigger or retry a delivery from the dashboard.
  3. Open the WebhookSink UI and compare the received headers, payload, verification status, and duplicate count.

Expected outcome

  • Webhook endpoint setup and delivery inspection work as one coherent product flow.
  • Signature verification and replay-protection behavior are visible without backend log diving.
  • Any mismatch between event contract, dashboard delivery state, and sink payload becomes explicit.