Multi-brand operations
If you manage multiple brands, regional sub-brands, or client domains, you need predictable routing and naming that scales without cross-brand interference. Nimriz makes each domain fully isolated by design.
- Domain-bound slugs - same short code, completely different destinations per brand
- Strict host matching - no apex/www aliasing, no cross-client collisions
- Per-domain fallback configuration for root, not-found, and expired links
The same slug exists independently under each client domain - no collision.
Agencies and multi-brand teams face a structural problem with most link shorteners: a single shared namespace means the same slug can only point to one destination, forcing teams into awkward naming conventions, separate accounts, or accepting that two campaigns on two brands will eventually collide. The workarounds compound over time - different slugs per brand, different accounts to manage, different dashboards to check - until the operational overhead outweighs the convenience of short links altogether.
Nimriz solves this at the architecture level. Short links are keyed by host and short code together, not by short code alone. That means brand-a.to/launch and brand-b.to/launch are fully independent records. They can point to different destinations, carry separate click histories, and be managed by different team members - all from the same workspace. You add a domain per brand, verify DNS ownership, and every link you create under that host is automatically scoped to it.
Strict host matching reinforces this isolation. Nimriz treats apex and www as separate domain records with no silent aliasing. Reserved system paths such as /_health, /api/*, and /.well-known/* stay outside the slug namespace regardless of what short codes you create. Managed-domain loop prevention blocks any attempt to shorten a URL back into a Nimriz-managed redirect host, preventing redirect chains from folding back on themselves. The result is a routing model that is explicit at every step: host resolution comes first, then slug lookup within that host, then domain-configured fallback if nothing matches.
Workspace roles let an agency or in-house team manage all brand domains under one login while keeping access appropriate by role. You can review teams and security to understand the fixed owner, admin, member, and viewer roles that control who can create links, manage domains, and see analytics across your portfolio. Custom domains are available on supported plans - see branded links and domains for the full feature detail.
Who it is for
You manage short-link domains for multiple clients and need each client's slugs, analytics, and fallback pages kept entirely separate - without running separate Nimriz accounts.
Your company owns several distinct consumer brands, each with its own domain. You want consistent readable slugs like /sale or /app across every brand without namespace conflicts.
You run regional sub-brands or product-line microsites on separate hosts. You need campaigns on each host to resolve independently so regional click data stays clean.
You are building a scalable link infrastructure that a distributed team can use across brands. You need workspace-level access controls so each team member sees and touches only what their role allows.
What you get
Short codes are unique per domain, not globally. That means brand-a.to/spring and brand-b.to/spring are fully independent records pointing to entirely different destinations, with separate click counts. Separate brands can reuse the same slug conventions without any risk of cross-brand collision.
Host resolution happens before slug lookup, so routing stays explicit. Apex and www are treated as distinct domain records - example.com and www.example.com are separate entries with no silent aliasing between them. This means you always know which host resolved the redirect and there is no ambiguity about which brand a click belongs to.
Each domain gets independent root, not-found, and expired-link fallback URLs. When a visitor hits a broken or expired link on Client A's domain, they land on Client A's own branded fallback page - not a generic platform error and not Client B's destination. Each client controls exactly how their audience exits a dead link.
Click analytics are scoped per domain so Client A's traffic never appears in Client B's data. You can review performance for each brand independently and report clean per-brand numbers to stakeholders or clients without manually filtering a shared pool of click events.
How it works
Domain isolation by design
Short link lookups use a per-domain key - not just the slug - so the same slug can exist on brand-a.to and brand-b.to as fully independent links with different destinations and separate analytics.
Verify each branded domain via DNS. Nimriz validates the TXT record, marks the domain verified, and enables it for your workspace - strict host matching applies from the first redirect.
Create links scoped to a specific host. Every link is tied to one domain at creation time. The same slug is valid on every domain you own because lookups always combine host and short code.
Review per-brand analytics. Click data is scoped by domain so you can report clean per-brand numbers without filtering a shared click pool.
- Predictable resolution order: reserved paths block first, then short-code lookup within the matched host, then the domain-configured fallback if no slug matches.
- Redirects default to 302 so you can update destinations mid-campaign without stale browser caches picking up the old target.
- Reserved paths such as /_health, /api/*, and /.well-known/* are blocked globally so system-level paths never conflict with short codes, on any domain.
- Workspace roles (owner, admin, member, viewer) let a multi-brand team or agency control who can create links, manage domains, and view analytics across the portfolio.
Setup
- 1Verify each brand domain via DNSAdd your branded short domain to Nimriz and add the generated TXT record to your DNS provider. Once Nimriz verifies the record, the domain is marked verified and enabled for your workspace. Custom and branded domains are available on supported plans. See custom domain setup and DNS verification for step-by-step instructions.
- 2Create links scoped to each hostSelect a domain when creating a link. Every link is permanently scoped to the chosen host. Because lookups combine host and short code, the same slug - /launch, /app, /spring - is valid and independent on every verified domain you own. There is no global slug registry to coordinate across brands.
- 3Reuse readable slugs across brands safelyAssign the same short code to matching campaigns on different brand domains. Each instance resolves to its own destination and accumulates its own click history. See the domain-bound slug glossary entry for a plain explanation of how per-domain uniqueness works.
- 4Manage access by role across your brand portfolioWorkspace roles (owner, admin, member, viewer) let you give team members and clients the right level of access without granting blanket control. Admins can add domains and manage workspace settings; members can create and edit links; viewers can review analytics. See organizations and workspaces for the full role reference.
- 5Report per brand using domain-scoped analyticsClick analytics are tied to the domain that resolved each redirect. Pull per-brand reports from your workspace without filtering a shared click pool. Each brand's traffic, referrers, and geographic breakdown stays in its own reporting scope. Combine with spaces and tags to add campaign-level organization within each brand.
What good looks like
Before: one shared shortener
- Single shared domain means slug /spring can only point to one destination
- Cross-brand slug collisions force awkward naming: /brand-a-spring, /brand-b-spring
- Apex and www may be silently aliased, making routing ambiguous
- No structural guarantee that Client A links are separate from Client B links
- Broken links on one brand can expose a generic platform error to another brand's audience
After: isolated verified domains
- Each brand runs on its own verified domain - brand-a.to and brand-b.to are structurally separate
- Per-domain slug uniqueness means /spring is a valid, independent slug on every domain
- Strict host matching: apex and www are distinct records, no silent aliasing
- Reserved paths and loop prevention apply on every domain - no system-path conflicts, no redirect loops
- Per-domain fallback URLs send each brand's audience to that brand's own page on broken or expired links
Each brand domain resolves independently. Same slugs, different destinations, separate analytics - with no coordination overhead between brands.
Frequently asked questions
Can the same slug exist on two different brand domains?
How does custom domain setup work?
Are apex and www treated as the same domain?
How is access controlled across multiple brand domains in one workspace?
What plan do I need for custom branded domains?
What stops a link from looping back into Nimriz?
Are system paths like /api or /.well-known ever available as slugs?
Can I manage agency client domains separately even if they share a workspace?
Related use cases
Deeper reading
Ready to get started?
Create your account and start with the Starter workflow. Compare plans when you need higher limits or supported-plan capabilities.