Before you start
Lamba docs use product-facing names consistently. Workspace is the operating and billing boundary. Project is the runtime product boundary. Lamba User is the person-level identity that can hold console access, product access, or both.
What you build
A Lamba integration connects five layers:
| Layer | Meaning | Common docs |
|---|---|---|
| Lamba User | The global identity actor. | Auth, sessions, profile, linked providers |
| Workspace | The builder-owned operating boundary. | Team, billing, plans, settings |
| Project | The product/runtime boundary. | Customer auth, roles, webhooks, growth |
| Session | The current authenticated access path. | Login, refresh, revoke, scoped access |
| Event | A durable fact that downstream systems can consume. | Webhooks, audit, campaign, loyalty |
Implementation steps
- Start with the product surface the user enters.
- Map that surface to a Project.
- Decide whether the person is a Team Member, Project Member, or both.
- Use the Project role catalog for runtime access.
- Use webhooks and audit events for downstream automation instead of duplicating identity state.
Access model
Team Members control console access through Workspace roles and optional Project console roles. Project Members control runtime product access through Project roles. Promoting a user to Team Member changes console access only; it does not assign runtime Project roles.
Growth model
Growth workflows should consume identity facts rather than create a second customer graph. Campaigns, loyalty, segments, analytics, and notifications should stay attached to the same Lamba User, Project, environment, session, and event context.
Security and operational notes
- Keep production and sandbox credentials separate.
- Read effective authorization before showing privileged runtime UI.
- Treat webhook payloads as immutable facts.
- Keep audit and delivery logs tied to the Workspace and Project that produced them.
Troubleshooting
If an access decision is confusing, identify the surface first. Console access comes from Team Member context. Runtime product access comes from Project Member context. API calls should use token-scoped context on public customer hosts, not internal console headers.
Related docs
- Workspaces and Projects:
/docs/concepts/tenant-project - Roles and Permissions:
/docs/concepts/roles-permissions - Scoped Sessions:
/docs/concepts/scoped-sessions - Growth Workflows:
/docs/growth/overview