Lamba

Overview

Use workspace-owned domains to expose branded customer auth and customer API hosts.

Each host binds to one project, one environment, and one purpose:

auth
api

Typical setup:

auth.customer.com
api.customer.com

Important issuer rule

The auth host is the issuer.

If discovery is served from https://auth.customer.com/.well-known/openid-configuration, your verifier must trust https://auth.customer.com as iss.

1) Add domain in workspace settings

Add your custom host.
Retrieve the verification token.

2) Publish DNS verification record

name:  _lamba-verification.<custom-host>
type:  TXT
value: <verification-token>

3) Verify domain

Trigger domain verification from workspace domain settings until status becomes verified.

4) Add project and environment bindings

Bind the verified host to:

project
environment (test or prod)
purpose (auth or api)

Bindings are fail-closed. A host without a matching project and environment binding must not serve customer traffic.

5) Configure OIDC client

Register exact redirect URIs for the branded auth host.
Keep environment-specific clients and bindings separate.
Keep strict URI matching; no wildcards.

6) Validate runtime behavior

Unverified host should fail with custom_domain_not_verified.
Missing or wrong binding should fail closed.

7) Production checklist

TLS certificate valid for both auth and api hosts.
Redirect URIs match the branded auth host exactly.
Issuer matches the branded auth discovery host.
Monitoring covers auth, callback, and customer API failures.

Next steps

OIDC security model: /docs/reference/oauth-oidc-security
Environments: /docs/concepts/environments

Custom Domains Quickstart