Every project gets a subdomain from its slug:
https://{projectPrefix}.dynalink.app/{code}
A project can also serve its links from its own host — https://links.yourbrand.com/{code} —
which is what you want when the link is the first thing a user sees in an ad, an
SMS or a social post.
Three steps:
CNAME to dynalink.app, and make sure
the TLS certificate covers the host. DynaLink resolves the project from the
request host, so nothing else is needed on our side.intent-filter on Android and the
applinks: entry on iOS must list the custom domain, otherwise the OS will
keep sending it to the browser.Android and Apple fetch the association files from the exact host that serves the link, so a custom domain needs its own copies. DynaLink serves them for you at both locations once you have uploaded them in the Admin Panel:
GET https://{projectPrefix}.dynalink.app/.well-known/assetlinks.json
GET https://{projectPrefix}.dynalink.app/.well-known/apple-app-site-association
GET https://{yourdomain}/.well-known/assetlinks.json
GET https://{yourdomain}/.well-known/apple-app-site-association
See the Android App Links and Apple Associated Domains references for the file contents.
GET https://dynalink.app/api/projects/link-domains
Lists the hosts allowed to serve this project's links. The Flutter SDK calls it to
recognize incoming links from a custom domain that was not declared in
initialize. Requires the x-project-key header.
curl https://dynalink.app/api/projects/link-domains \
-H "x-project-key: YOUR_PROJECT_KEY"
{
"main_domain": "dynalink.app",
"subdomain": "yourprefix.dynalink.app",
"custom_domains": ["links.yourbrand.com"]
}
Dynalink.initialize(customDomains: [...])) avoids this round-trip and works on the very first link, offline included.