Skip to main content

Properties

A single Allegro organization can run multiple properties — distinct brands that share the organization's members, entitlements, and templates but present their own web address, CORS rules, cookie domain, and email identity. When an organization uses properties, each property is reachable at its own host, and the Allegro SDK targets a property by the host it is loaded from — no extra configuration in your embed code.

For configuring properties in the dashboard, see the Properties product guide. This page covers what changes for a developer embedding the SDK on a property.

Property Hosts​

Each property has a dedicated subdomain that combines the organization slug and the property slug with a double-hyphen separator:

https://{organization}--{property}.allegrocdp.com

For example, an organization acme with a property magazine is served at:

https://acme--magazine.allegrocdp.com

The double hyphen (--) is the reserved separator between the organization and the property. This is why property and organization slugs cannot contain consecutive hyphens. A plain organization host with no -- (for example acme.allegrocdp.com) refers to the organization itself, not to any property.

Targeting a Property from the SDK​

The SDK determines which property it operates as entirely from the host that serves client.js. There is no data-property attribute — you select a property by loading the SDK from that property's host:

<!-- All SDK and API traffic is scoped to the "magazine" property -->
<script
    src="https://acme--magazine.allegrocdp.com/client.js"
    data-tenant="acme"
></script>

The SDK's API base URL defaults to the origin of client.js, so every request it makes — authentication, event tracking, interactions, checkout — is automatically scoped to the property. Loading client.js from the plain organization host instead targets the organization with no property context.

No SDK code changes

Switching a page from the organization host to a property host — or between two properties — requires changing only the src of the script tag. The SDK, web components, and API calls behave identically; only the property context differs.

Custom Domains for a Property​

A property can be served from a domain you control instead of the default {organization}--{property} subdomain. Set the property's Custom Domain in the dashboard and point its DNS at your Allegro instance. Once configured, load the SDK from the custom domain:

<script src="https://members.acme.com/client.js" data-tenant="acme"></script>

A property custom domain works like a tenant Custom Domain: audience-facing SDK and API paths are served on it, and all other paths redirect to the organization dashboard. A custom domain must be unique across the entire Allegro instance — it cannot collide with another organization's or another property's domain.

What the Property Changes​

Once a request resolves to a property, Allegro layers the property's configuration on top of the organization's. From an integration standpoint, three things differ:

CORS​

The property's allowed origins are merged on top of the organization's — the property extends the origin list, it never replaces it. The property's own web address (subdomain and custom domain) is always allowed. Configure additional origins, including https://*.acme.com wildcard patterns, in the property's Browser Settings.

The same allowed-origin list governs return URLs. The returnUrl passed to magic link requests and the return URL passed to checkout must resolve to an allowed origin, otherwise the request is rejected.

The SDK's client configuration reports the property's cookie domain when one is set, falling back to the organization's cookie domain when the property leaves it blank. This controls the domain the member session cookie is scoped to.

Email Templates​

Transactional emails triggered on a property host render that property's template if one exists, falling back to the organization's template, then to Allegro's built-in default. This resolution is preserved even for emails sent from a queue — the property context is captured when the email is created.

API Behavior​

The API on a property host behaves identically to any organization host. Requests under /api/* always return JSON, including a structured error envelope:

CodeHTTP statusMeaning
NO_CURRENT_TENANT404The host did not resolve to an organization.
VALIDATION_ERROR422The request failed validation.
UNAUTHENTICATED401Authentication is required or the token is invalid.
FORBIDDEN403The authenticated member may not perform the action.
NOT_FOUND404The resource does not exist.

The property only augments the request's CORS, cookie, and email/template context — it does not change the API surface, authentication, or response shapes.