Deep Blue Links
Documentation menu

Apps

An app's settings decide its link host, the verification files iOS and Android read, and what the preview page's buttons open.

Each app's links live on https://{name}.dev.thedbl.ink, where {name} is the app's name. A name is a DNS label: letters, digits and inner hyphens, at most 63 characters, unique across Deep Blue Links regardless of case.

Links carry the host in their URLs, and iOS and Android trust the host because of the files below. Renaming an app moves its host, so links created before keep the old host, which no longer verifies for your app, and stop opening it. Pick a name you'll keep.

You can also serve links from your own domain: see Custom domains.

iOS

Deep Blue Links serves the Apple App Site Association file at https://{name}.dev.thedbl.ink/.well-known/apple-app-site-association:

{
  "applinks": {
    "apps": [],
    "details": [
      { "appID": "ABCDE12345.com.example.demo", "paths": ["/*"] }
    ]
  }
}
  • Team ID: the 10-character ID of your Apple developer team. Together with the bundle ID it forms appID.
  • Bundle ID: your app's bundle identifier.
  • Paths: the URL paths iOS opens your app for. Leave them empty for every path, /*. With narrower paths, remember that short URLs are one segment long (/Xy3kP9aQ), so keep a pattern that covers them.

Your app must also list the host in its Associated Domains entitlement as applinks:{name}.dev.thedbl.ink. The iOS guide shows how.

Android

Deep Blue Links serves the Digital Asset Links file at https://{name}.dev.thedbl.ink/.well-known/assetlinks.json:

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.demo",
      "sha256_cert_fingerprints": ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
    }
  }
]
  • Package name: your app's application ID.
  • SHA-256 certificate fingerprints: one for each key that signs a build you want links to open. With Play App Signing, add the app signing key's fingerprint from the Play Console; add your upload key's and your debug keystore's for builds you install yourself. Android verifies the link host only for apps signed with a listed key.

URL scheme

A custom URL scheme is optional. When the app has one, the preview page's Open the App button uses it: on iOS the button opens {scheme}:// followed by the link's path and query without the leading slash, such as myapp://products/1234, and on Android it opens the same URL through an intent that falls back to Google Play. Without a scheme, iOS shows Get the App instead, because a page can't tell whether the app is installed, and Android opens the short URL in your app.

A scheme URL puts the first path segment in the URL's host: myapp://products/1234 has host products and path /1234, so join them to route it like /products/1234.

The scheme is stored lowercase without ://. It's a letter followed by letters, digits, +, - or ., 2 to 64 characters, and it can't be http, https, intent or a scheme a browser runs or loads, such as javascript, data or file.

API keys

An app has a live key and can have a sandbox key. You generate each on the app's page, which shows it once; generating a key again replaces only that kind, so rotating the sandbox key never touches your live servers. See Authentication and Sandbox links.