Request Scoping

Two scoping models

Lamba has two HTTP surfaces with different context rules:

1. Customer public surface

• Hosts: id.uselamba.com and api.uselamba.com
• Context comes from the customer session token.
• Do not send X-Tenant-Id or X-Project-Id.

2. Internal platform surface

• Host: platformapi.uselamba.com
• Used by the Lamba app and console.
• Tenant and project headers still scope platform reads and writes.

Customer public scoping

• Unauthenticated auth flows resolve their default workspace/project/environment from the auth host and configured bindings.
• Authenticated runtime/admin flows resolve active workspace + project + environment from the issued session token.
• Password, register, magic-link, phone, refresh, and switch-context all issue that customer session token shape.
• OIDC Authorization Code flow signs the user in on id.*, but you should exchange into a scoped customer session before calling api.*.
• If your app pins users to a specific project, call POST /v1/sessions/switch-context after login or register.

Internal platform scoping

Internal platform requests still use:

Authorization: Bearer <access-token>
X-Tenant-Id: <workspace-guid>
X-Project-Id: <project-guid>

This is an internal console/app contract, not a customer runtime contract.

Best practices

• Customer products should talk only to id and api.
• Lamba app and console should talk only to platformapi.
• Keep X-Correlation-Id on both surfaces for traceability.
• Never infer workspace or project from untrusted client input without membership validation.

Related docs

• Workspace/project model: /docs/concepts/tenant-project
• API contract: /docs/reference/api-overview
• Error handling: /docs/reference/errors