Every Optimove Web SDK configuration request is resolved to a brand by looking at the domain from which the request came. If you map that domain explicitly, the SDK receives that brand's configuration. If you don't, the platform falls back to the tenant's Default Brand when one is set, and returns nothing when one isn't.

This page covers how that resolution works, the constraints it operates under, and how to verify it during integration. The mappings themselves are configured by operators in the Optimove portal.

For the operator configuration steps, see the Domain Management article in the Optimove Academy.

Resolution Order

For each Web SDK configuration request, the domain — taken from Referer, falling back to Origin — is resolved in this order:

1. Exact domain mapping → serve that brand's configuration.
2. Wildcard domain mapping → serve that brand's configuration. If several wildcards match, the most specific one wins: fewest * characters, most literal text.
3. Default Brand, if one is set → serve the fallback brand's configuration.
4. Otherwise → serve nothing.

Only one Default Brand can be set per tenant.

Browser Traffic Only

The Default Brand only fires when the request carries a parseable Origin or Referer — that is, real browser traffic. If the host can't be parsed, resolution stops and nothing is returned; the Default Brand does not fire.

This matters when you integrate and test:

• Requests from curl, Postman or server-side scripts won't receive the Default Brand, or any brand. This is by design, not a bug.
• Test the Default Brand from a browser on the domain in question, not from a command-line tool.

Configuration

Domain mappings and the Default Brand are set by operators in the Optimove portal, under Settings > Web > Domain Management. There is no SDK method or public API for setting them.

There is nothing to implement in your SDK code to consume a fallback configuration: a config served via the Default Brand is indistinguishable to the SDK from one served via an explicit mapping.

Propagation

Configuration changes can take up to 10 minutes to take effect, because domain configuration is cached. This is the same propagation behaviour as ordinary domain mappings. Allow for this window before concluding a change hasn't worked.

Verifying

1. From a browser, load a page on the domain in question with the SDK installed.
2. In DevTools → Network, confirm a successful Web SDK configuration request.
3. Confirm the served configuration corresponds to the brand you expect.
4. If it doesn't, check that 10 minutes have elapsed, and that no broader exact or wildcard mapping is catching the domain first.

For the wider SDK integration flow, see the Web SDK Integration guide.

Related

• Web SDK Integration
• Verifying the SDK Implementation
• Web Push Platform Setup — its Domain Management prerequisite should be updated to link here as well
• SDK Setup & Local Development
• Domain Management — Academy operator guide