Native routing

In addition to standard web-based (HTTP / HTTPS) routing, a link resource can be configured to redirect the visitor to a specific page/screen/content inside a native application installed on the device, given the application is configured to support routing behaviors at all. This practice is generally referenced to as "deep linking" (linking to a deep, usually nested, location within the app or website).

📘

Native routing / deep links feature

Native routing is a paid feature and may not be available with all subscriptions.
In pricing, it is labeled "Deep links" for convenience.

In case you own a device-specific application, or you wish to redirect your links to a third-party known application which supports deep linking, the Rebrandly Dashboard already includes ways to accomplish this.

General Availability notice

If your use-case includes deep linking strategies, please do not hesitate to reach out to our support to get private guidance on deep links API integration.

Feature showcase, from a technical standpoint

🚧

Manual step required

Please acknowledge that an A-Z API integration is not possible. A manual setup step is first required to be operated from the Rebrandly Dashboard to associate a native app to a Rebrandly workspace. Once apps are available and verified in the workspace, you can associate them with links programmatically.

In order to use a device-specific application's deep location as landing URL for your links, you need to get such an application approved in the Rebrandly workspace context. You can achieve this using the Rebrandly Dashboard wizard while creating a new link (Link options - Deep links) or while defining a workspace's set of apps (Workspaces - Workspace detail - Apps - Add a new app).

Applications will only be accepted if Rebrandly is able to verify they are already published on either the Google Play Store or the App Store.

👍

No Broken Links policy

A Rebrandly link's destination URL field is not suitable for links with any protocols different than HTTP and HTTPS. This specific restriction is meant to guarantee a stable experience to the end-user, in that a link with any other protocol is not guaranteed to be supported on the browser performing the routing step.

Packaging native routing as a different add-on feature allows Rebrandly to react to different scenarios and to build fault-tolerant fallback routing strategies.

Following this "No Broken Links" policy, Rebrandly links have been enhanced to support, in addition to the default destination URL, a set of additional routing instructions to cope with different scenarios.

Example scenario and supported fallback options

This example you can fully implement programmatically.

If a link resource is found to be associated with a Native routing rule which expects an iOS application to be installed on the device, this is how the above policy would apply:

• If the device is not running the iOS operating system at all, the link's default destination URL will be selected as the final landing URL

• if the device is running the iOS operating system, and the iOS application is found to be available on the device, the deep location inside such application is going to be selected as the final landing URL

• if the device is running the iOS operating system, but the iOS application is not found to be available on the device, you will be able to choose among different options Rebrandly provides for this edge-case:

  • you can either redirect end-users to the App Store for them to install the app first and then be redirected to the intended content

or

• you can redirect end-users to another web URL

or

• you can prompt end-users to choose where to go next so that they can either choose to install the application or they can go for the web alternative, instead