Domains: default vs custom
Every OptoLink link carries its brand in the hostname: https://{domain}/{org-key}/{shortCode}. This page explains the two kinds of hostname, who controls each, and the lifecycle a custom domain passes through. The click-by-click steps are in Custom domains.
The platform default domain
Every organization links from one shared OptoLink domain out of the box. It's included on every plan, needs no setup, and can't be renamed or removed. The {org-key} path segment is what separates organizations on it; the hostname is the same for everyone.
Two consequences of it being shared:
- App deep linking works from the start: the universal-link and app-link association files served on the default domain cover all organizations at once.
- Nothing you do with custom domains can break the default. It has no lifecycle and no actions in the portal.
What a custom domain adds
A custom domain is your own hostname, such as links.yourbrand.com, used instead of the default. Your links become fully branded: your host, your org key, your short codes. Custom domains are a plan feature: they open up at Solo, with a per-plan amount (see Plans, quotas & entitlements).
Association files on a verified custom domain serve only your organization's app configuration, so universal links and app links follow your brand too.
Why verification runs through a review
OptoLink doesn't verify custom domains by checking DNS automatically. A request goes into a review queue handled by the OptoLink team: they approve it, verify the setup, and deploy the domain. You add the CNAME record while the request waits; the record alone never changes the status.
The practical consequences: verification time depends on the review rather than on DNS propagation, and the decision arrives on the domains list, which refreshes every 30 seconds. No email is sent.
The lifecycle
A custom domain moves through five statuses:
| Status | Meaning | Reached by |
|---|---|---|
| Requested | Waiting in the review queue. | Submitting a request, or re-requesting a rejected domain. |
| Approved | Accepted; deployment in progress. | The team approving the request. |
| Verified | Live; can be attached to links. | The team completing verification. |
| Rejected | Denied; the reason shows on the card. | The team rejecting the request. |
| Removing | In its 30-day grace window. | Deleting a Verified domain. |
The transitions around them:
- Requested → Approved → Verified is the happy path. States can't be skipped; each step is a separate review action.
- Requested or Approved → Rejected comes with a reason on the card. Re-request returns a rejected domain to Requested.
- Verified → Removing happens when you delete. Links keep resolving for 30 days, and Cancel Removal restores Verified at any point in the window.
- Removing → deleted when the window ends. Links on the domain are removed with it, and link templates that pointed at the domain lose that setting.
Only Verified domains can be attached to links. A link already attached to a domain keeps resolving throughout the removal window.
Deletion is staged, removal is not
Whether deletion is immediate or staged follows one question: does the domain already carry live links?
- A Verified domain is never deleted outright. Deleting starts the 30-day grace window so traffic on existing links drains instead of dying.
- A domain that isn't live yet (Requested, Approved, Rejected) has no links on it, so it deletes immediately.
- Once the grace window ends, removal is permanent; re-requesting the same hostname starts a fresh review.