Creating Routes

Creating a route

1. Go to Routes in the sidebar and click Create Route.

2. Choose the link type: Dynamic (with a :token parameter) or Static (fixed path).

3. Enter a prefix. This is the URL path for your route. For example, if you enter invite, your links will look like https://your-domain.tolinku.com/invite (static) or https://your-domain.tolinku.com/invite/abc123 (dynamic).

4. Give it a name. This is an internal label shown in the dashboard and analytics. It is not visible to users.

5. Configure the remaining settings (landing page, fallback URL, OG tags) and click Save.

Prefix rules

The prefix is the most important part of your route. It defines the URL path and cannot be changed after creation without creating a new route.

• Length: 3 to 63 characters, counting the whole path
• Characters: Lowercase letters, numbers, and hyphens, plus slashes to make a path
• Depth: Up to three words, plus :token on a dynamic route, so four parts in all
• Restrictions: No part can start or end with a hyphen, and the first part cannot be :token
• Uniqueness: No two routes in an Appspace can answer the same path

Prefixes with a path

A prefix can be a path rather than a single word, so your links can mirror the structure of your own website:

Prefix	Static link	Dynamic link
promotion	/promotion	/promotion/abc123
new/promotion	/new/promotion	/new/promotion/abc123
kr/store/new	/kr/store/new	/kr/store/new/abc123

Putting the token somewhere other than the end

By default a dynamic route’s token goes on the end. Write :token in the prefix to put it where your own URLs put it:

Prefix	Link
product	/product/abc123
product/:token/reviews	/product/abc123/reviews
merchant/:token/menu	/merchant/abc123/menu

This is for the common case where a resource has sub-pages, so /product/123 and /product/123/reviews are two routes rather than one route and a token your app has to pick apart.

A route with :token in the middle still answers at its root, with the token and its slash removed. product/:token/reviews answers /product/reviews as well, the same way product answers /product.

One :token per route, and it cannot be the first part.

When two routes could both answer

A literal always wins over a token. If you have product/:token/reviews and product/summary/reviews, then /product/summary/reviews opens the second one and /product/anything-else/reviews opens the first.

The same rule settles a prefix against a token: with a route on new and a route on new/promotion, /new/promotion opens the second and /new/anything opens the first with anything as its token.

What you cannot have is two routes that claim exactly the same path. A dynamic route new and a dynamic route new/:token are the same route written two ways, and the second one is refused with the name of the route already answering it.

Caution

Some prefixes are reserved and cannot be used: auth, dashboard, api, v1, health, webhooks, well-known, onboarding, account, admin, bio. This applies to the first part of a path, so health/promotion is reserved too.

Landing page behavior

Each route can use one of three landing page modes:

• Generic: A branded landing page with your app name, logo, and download buttons. Works well for most links.
• Custom: A page you design using the visual builder. Choose from templates or build from scratch.
• None: No landing page. The user is immediately redirected to the app, store, or fallback URL.

For dynamic routes, the default is Generic. For static routes, the default is None (direct redirect).

Fallback URL

The web fallback URL determines where users go when they cannot open your app (desktop browsers, users without the app). If you leave this empty, the route falls back to the Appspace-level fallback URL set in App Config.

A typical setup:

Scenario	Destination
Mobile, app installed	Opens directly in the app
Mobile, no app	App Store or Play Store
Mobile, back from the store	Your fallback URL, unless you switch that off
Desktop	Your fallback URL (e.g. marketing site)

Forwarding query parameters

By default, query parameters on the clicked link are recorded for analytics but not passed to the destination. Switch on Forward query params and Tolinku copies the query string onto the fallback URL, the app deep link, and your landing page buttons.

See Forwarding Query Parameters for the forwarding rules and examples.

Where mobile visitors land

A visitor who already has your app never reaches Tolinku: the operating system opens the app directly. For everyone else, the landing page mode decides what they see, and a route setting decides whether a direct redirect goes to the app store or to your Fallback URL.

Coming back from the store is covered by the same setting group: by default a visitor who returns to the hand-off page is sent on to your Fallback URL rather than left on a page that says it is opening a store they have already seen.

See Mobile Destinations, which also covers overriding the destination per link and passing one on the link itself with deep_link_value.

Universal Links and App Links

By default, every route is included in your Apple App Site Association (AASA) and Digital Asset Links files. This means iOS and Android will open your app directly when a user taps the link, without showing a browser first.

You can disable this per route if you want certain paths to always open in the browser. Toggle the Universal Links / App Links setting on the route form.

This setting is overridden when the Appspace attributes app opens with Always, which holds every link back from the operating system so the tap can be counted. See Attributing app opens.

Configuration checklist

The route form shows a checklist to help you track what has been configured:

• Prefix and name (required)
• Fallback URL
• Universal Links enabled
• OG tags
• API endpoint (dynamic routes)

You do not need to complete everything before saving. Only the prefix and name are required.