> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

> Describes placeholders, including wildcard and organization placeholders, for subdomains function in application configuration.

# Subdomain URL Placeholders

You can use various placeholders to act as dynamic text entries in your URLs.

## How URL evaluation works

A URL containing an `{organization_name}` placeholder will only be evaluated when all the following conditions are met:

* The application has the `organization_usage` set to `allow` or `require`
* A transaction was performed in the context of an organization (for example, initiating an authorization transaction with the organization parameter: `/authorize?organization=org_bVss9Do3994SIbiH&…`)

URLs with the `{organization_name}` placeholder will be evaluated in addition to exact match URLs (`https://app.exampleco.com`) and URLs with wildcards (`https://*.exampleco.com`). You must not rely on any specific order of evaluation of the URLs.

Avoid registering URLs with wildcard and Organization placeholders in the same configuration field for an application as it may lead to undesirable behavior and make troubleshooting difficult. As an example, consider an application with two **Allowed Callback URLs**: `https://*.exampleco.com` and `https://{organization_name}.exampleco.com`. A `redirect_uri` with the value of `https://company-a.exampleco.com` would be considered valid even if there were no Organizations with the name `company-a` registered in your tenant; this is due to the evaluation of the wildcard placeholder.

## Wildcard URL placeholders

Wildcard placeholders in subdomains **should not** be used in production applications. Auth0 recommends URLs with the `{organization_name}` placeholder where relevant.

<Warning>
  Wildcard URL placeholders are not supported for [third-party applications](/docs/get-started/applications/third-party-applications) with enhanced security controls. Callback URLs, allowed origins, and web origins must use exact URLs.
</Warning>

Manage these settings in [Dashboard > Applications > Applications](https://manage.auth0.com/#/applications) in the following fields:

* **Allowed Callback URLs**: List of URLs to which Auth0 is allowed to redirect users after they authenticate.
* **Allowed Logout URLs**: List of URLs to which you can redirect users after they log out from Auth0.
* **Allows Web Origins**: List of URLs from where an authorization request using [Cross-Origin Authentication](/docs/authenticate/login/cross-origin-authentication), [Device Flow](/docs/get-started/authentication-and-authorization-flow/device-authorization-flow), and [web\_message as the response mode](/docs/authenticate/protocols/oauth) can originate.
* **Allowed Origins (CORS)**: List of URLs that will be allowed to make requests from JavaScript to Auth0 API (typically used with CORS).

Avoid using wildcard placeholders for subdomains in production application callbacks and allowed origins as it can make your application vulnerable to attacks.

You can use the star symbol (`*`) as a wildcard for subdomains, but it must be used in accordance with the following rules in order to properly function:

* The protocol of the URL **must** be `http` or `https`. Protocols such as `com.example.app` and `service:jmx:rmi` will not work.
* The wildcard **must** be located in a subdomain within the hostname component. `https://*.com` will not work.
* The wildcard **must** be located in the subdomain furthest from the root domain. `https://sub.*.example.com` will not work.
* The URL **must not** contain more than one wildcard. `https://*.*.example.com` will not work.
* A wildcard **may** be prefixed and/or suffixed with additional valid hostname characters. `https://prefix-*-suffix.example.com` will work.
* A URL with a valid wildcard **will not** match a URL more than one subdomain level in place of the wildcard. `https://*.example.com` will not work with `https://sub1.sub2.example.com`.

## Organization URL placeholders

### Organization name placeholder

You can use `{organization_name}` as a placeholder to dynamically specify a registered Organization's name in a URL (`https://{organization_name}.exampleco.com`). URLs with the `{organization_name}` placeholder should only be used on domains that you fully control. For example: If you control tge domain `exampleco.com`, then the placeholder with your Organization name is `https://{organization_name}.exampleco.com`.

Manage these settings in [Dashboard > Applications > Applications](https://manage.auth0.com/#/applications) in the following fields:

* **Allowed Callback URLs**: List of URLs to which Auth0 is allowed to redirect users after they authenticate.
* **Allowed Origins (CORS)**: List of URLs that will be allowed to make requests from JavaScript to Auth0 API (typically used with CORS).

The following restrictions apply when using the `{organization_name}` placeholder:

* The protocol of the URL must be `http:` or `https:`. `com.example.app://{organization_name}.exampleco.com` will not work.
* The placeholder must be located in a subdomain within the hostname component. `https://{organization_name}` or `https://exampleco.com/{organization_name}` will both not work.
* The placeholder must be located in the subdomain furthest from the root domain. `https://sub.{organization_name}.exampleco.com` will not work.
* The URL must not contain more than one placeholder. `https://{organization_name}.{organization_name}.exampleco.com` will not work.
* A placeholder must not be prefixed nor suffixed with additional valid hostname characters. `https://prefix-{organization_name}-suffix.exampleco.com` will not work.
* A placeholder **must not** be used in conjunction with a wildcard in the URL. `https://{organization_name}.*.exampleco.com` will not work.

### Organization metadata placeholder

You can use `{organization.metadata.KEY}` as a placeholder to dynamically specify a URL based on metadata associated with the Organization in the current request. This is useful when different Organizations require different login URIs, such as when each Organization maps to a separate vanity domain.

The `KEY` must start with `public_` or `PUBLIC_` (for example, `{organization.metadata.public_login_host}`). Keys without this prefix are ignored at runtime for security reasons.

Auth0 supports this placeholder for application login URI (initiate\_login\_uri). To learn more, read [Dynamic login URIs with metadata placeholders](/docs/authenticate/login/auth0-universal-login/configure-default-login-routes).

The same [validation rules](#validation-rules) that apply to custom domain placeholders also apply to Organization metadata placeholders (protocol, location, nesting, no wildcards, data type).

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Organization metadata placeholders require the request to be in the context of an Organization. If no organization is present, the placeholder cannot be resolved and Auth0 falls back to the tenant-level `default_redirection_uri`.
</Callout>

## Custom domain URL placeholders

You can use `{custom_domain.metadata.KEY}` as a placeholder to dynamically specify a URL based on metadata associated with the custom domain used in the request. This allows you to support multiple custom domains with different application URLs within the same tenant.

For a comprehensive overview of this feature, see [Multiple Custom Domains](/docs/customize/custom-domains/multiple-custom-domains)

### Validation rules

<Warning>
  Metadata values used as URL placeholders may be exposed to end users during authentication flows. Do not use sensitive metadata in placeholders. All metadata keys used in placeholders must begin with `public_` to make this explicit.
</Warning>

The following restrictions apply when using Custom Domain placeholders:

* **Public prefix required**: The metadata key used in the placeholder must start with `public_` or `PUBLIC_` (for example, `{custom_domain.metadata.public_callback_subdomain}`). Keys without this prefix are ignored at runtime for security reasons.
* **Protocol**: The protocol of the URL must be `http` or `https`.
* **Location**: The placeholder must be located in the domain or subdomain component. It cannot be used in the URL path.
  * Valid: `https://{custom_domain.metadata.public_app_url}.example.com/login`
  * Invalid: `https://example.com/{custom_domain.metadata.public_path}`
* **Nesting**: You cannot access nested metadata properties. Only top-level keys are supported.
* **No wildcards**: A custom domain placeholder must not be used in conjunction with a wildcard (`*`) in the same URL.
* **Data type**: The value in the custom domain metadata must be a String. If the key does not exist, or the value is not a String, the URL is ignored during validation.

### Supported fields

These placeholders can be configured for the following Application URLs:

* Allowed Callback URLs
* Allowed Logout URLs
* Allowed Web Origins
* Allowed Origins (CORS)
* Application Login URI (`initiate_login_uri`). To learn more, read [Dynamic login URIs with metadata placeholders](/docs/authenticate/login/auth0-universal-login/configure-default-login-routes#dynamic-login-uris-with-metadata-placeholders).

For more information, see [Application Settings](https://auth0.com/docs/get-started/applications/application-settings#application-uris).

<Note>
  Custom domain placeholders are not supported for third-party applications.
</Note>

### Using with Organization placeholders

You can combine the Custom Domain placeholder with the `{organization_name}` placeholder, as long as your flow supports it. Both placeholders are evaluated and replaced at runtime.

## Learn more

* [Confidential and Public Applications](/docs/get-started/applications/confidential-and-public-applications)
* [First-Party and Third-Party Applications](/docs/get-started/applications/first-party-and-third-party-applications)
* [Enable Third-Party Applications](/docs/get-started/applications/third-party-applications/configure-third-party-applications)