Lamba

Choose this when

Use this path after basic auth works and you want branded customer hosts such as:

https://auth.customer.com
https://api.customer.com

Each host binds to one Project, one environment, and one purpose: auth or api.

Before you start

You need DNS access for the domain, a selected Workspace and Project, and a decision about whether you are configuring sandbox or production first.

Get credentials from Console

Credentials and configuration values
Value	Console source	Env var	Used for
Domain host	Integration > Domains > Add domain	`LAMBA_CUSTOM_DOMAIN_HOST`	Host name to verify and bind
Verification token	Integration > Domains > Domain details	`LAMBA_DOMAIN_VERIFICATION_TOKEN`	TXT record value for domain ownership verification
Project and environment	Top Project selector and environment badge	`LAMBA_PROJECT_ID and LAMBA_ENV`	Binding a verified host to the runtime context
Purpose	Integration > Domains > Bindings	`LAMBA_DOMAIN_PURPOSE`	`auth` for issuer/login host or `api` for Customer API host

Configure environment variables

LAMBA_CUSTOMER_API_BASE=https://test.api.uselamba.com
LAMBA_CUSTOM_DOMAIN_HOST=auth.customer.com
LAMBA_PROJECT_ID=<project-id>
LAMBA_ENV=test

Make the first request

You can manage domains from the console. Server-side admin automation can use the public admin domain routes with a customer admin session or management token.

POSThttps://test.api.uselamba.com/v1/admin/domains

Auth: Customer admin session or management token
Used for: Creates a domain verification record

curl -X POST "$LAMBA_CUSTOMER_API_BASE/v1/admin/domains" \
  -H "Authorization: Bearer $ADMIN_OR_MANAGEMENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "host": "auth.customer.com"
  }'

Publish the TXT record:

name:  _lamba-verification.auth.customer.com
type:  TXT
value: <verification-token>

Then verify and bind the domain:

curl -X POST "$LAMBA_CUSTOMER_API_BASE/v1/admin/domains/$DOMAIN_ID/verify" \
  -H "Authorization: Bearer $ADMIN_OR_MANAGEMENT_TOKEN"

Request fields

Request and response fields
Field	Type	Required	Meaning	Notes
`host`	string	Required	Fully qualified custom host to verify.	Example: `auth.customer.com`.
`purpose`	auth \| api	Required	Whether the binding serves auth/OIDC or Customer API traffic.	-
`projectId`	string	Required	Project that owns the runtime binding.	-
`environment`	test \| prod	Required	Environment that should serve traffic on this host.	-

Response fields

Request and response fields
Field	Type	Required	Meaning	Notes
`id`	string	Required	Domain record ID used for verify, bind, and delete operations.	-
`host`	string	Required	Custom host being managed.	-
`isVerified`	boolean	Required	Whether ownership verification has succeeded.	-
`status`	string	Required	Current domain lifecycle state.	-
`verificationToken`	string	Required	TXT record value to publish before verification.	-
`bindings`	array	Required	Project, environment, purpose, and binding status records.	-

Done when

The TXT verification record is published for the exact host.
The domain status is verified in `Integration > Domains`.
The host is bound to the expected Project, environment, and purpose.
OIDC discovery from a branded auth host returns that host as issuer.
Redirect URIs on App Clients use the branded host exactly where needed.

Troubleshooting

Symptom	Likely cause	Fix
Verification fails	TXT record missing, wrong name, or DNS not propagated	Check the `_lamba-verification.<host>` record and retry
Host fails closed	Missing Project/environment/purpose binding	Add the correct binding in `Integration > Domains`
Token validation fails	Validator still expects `id.uselamba.com` issuer	Read discovery from the branded auth host and update issuer config
Redirect fails	App Client redirect URI uses old host	Update `Integration > App Clients > Edit > Redirect URIs`

OIDC Integration: /docs/quickstart/oidc
OAuth/OIDC Security: /docs/reference/oauth-oidc-security
Environment Separation: /docs/concepts/environments
Customer API request and response contract: /docs/quickstart/customer-api