> ## Documentation Index
> Fetch the complete documentation index at: https://help.qrtub.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What Is a Destination?

> Where a scan is routed, the exact order QRtub checks when someone scans a code, and what a visitor sees when nothing resolves.

A Destination is where a scan ends up. It is a URL that QRtub either redirects to immediately or shows as a button on a Page — an inspection form, a maintenance system, a PDF manual, a phone number, a mobile app deep link.

The QR code itself never contains the Destination. It contains a Link, and the Link resolves to a Destination at the moment of the scan. That indirection is the whole point: you can change where a code goes without reprinting anything.

## Where Destinations are set

Destinations are set on the Item, on the Item's Destination tab:

* **Default URL** — the single Destination a Direct-Mode scan redirects to. This is the plain, unconditional URL.
* **Conditional routing rules** — an ordered list that can pick a different URL per scan based on the Item's data, the device, or the time.

If the Item's Link opens a Page instead, each Destination is a button on that Page — an ActionLink, Button, or Link section with its own URL. One Item can carry as many of those as you need. Which of the two behaviors you get is the Direct Mode / Page Mode choice, covered in [Direct Mode vs. Page Mode](/pages/direct-mode-vs-page-mode).

## The resolution order for a scan

For a scan that redirects (rather than opening a Page), QRtub checks **only that Item's own destination data**, in this order:

1. **Conditional routing rules**, if the Item has any enabled. Rules are evaluated top to bottom and the first match wins — see [Conditional Destinations & Rule Priority](/destinations/conditional-destinations).
2. **The Item's Default URL**, with any `{{bindings}}` resolved.
3. **Nothing.** If neither produces a usable URL, the visitor gets the "not ready yet" page below.

Two consequences catch people out:

**A URL whose bindings do not all resolve counts as no URL at all.** If your Default URL is `https://cmms.example.com/asset/{{item.equipmentID}}` and this Item's `equipmentID` is empty, QRtub does not send a half-built URL — it skips that URL and moves to the next step in the order. The same applies per rule.

**The Collection's default destination pattern is not consulted at scan time.** That pattern is stamped onto each Item when the Item is created and then belongs to the Item. Editing the pattern later changes nothing about Items that already exist. See [Default Destination for New Items](/collections/default-destination).

Note that an Item carrying enabled conditional rules always routes, even when its Collection is set to Page Mode — the rules take precedence over showing a Page. If the rules then match nothing and there is no Default URL, the Page is shown after all.

## Values go into a URL exactly as stored

Destinations can pull Item data straight into the URL with double-brace bindings, so one URL template serves every Item in a Collection:

```text theme={null}
https://app.example.com/inspect?id={{item.serial_number}}&site={{collection.name}}
```

Two limits worth knowing before you build one:

* **There is no automatic URL encoding.** The stored value is inserted character for character. A field containing a space, an `&`, or a `?` will break the link. Keep values that feed a URL simple, or use a field that holds an ID rather than a description.

Full syntax and the available namespaces are in [Field Bindings & URL Templates](/destinations/field-bindings).

## "This access link isn't ready yet"

When a scan resolves to an Item that is explicitly set to **Destination Link** but has no usable Destination, QRtub shows a plain page headed "This access link isn't ready yet". It displays the Link's own public URL and nothing else — never an internal Item, Collection, or team ID — plus an **Open in QRtub** button.

Who sees what:

* **Anonymous visitors** see the not-ready page. It tells them the code is assigned but has no destination yet, and that the owner may still be configuring it.
* **Signed-in members of the owning team** are sent instead to the authenticated view for that Link, where the Destination can be set. Membership is checked on the server before anything is revealed.

An Item that was never explicitly set to Destination Link does not show this page — it falls through to its Page instead. So a blank-looking Page and a not-ready page are two different symptoms: the first means no Destination buttons resolved, the second means the Item is meant to redirect and has nowhere to send anyone.

## Unsafe URLs are refused

QRtub blocks script-executing URL schemes — `javascript:`, `data:`, and `vbscript:` — wherever a Destination is used. Whitespace and control characters are stripped before the check, so tricks like `java\tscript:` are caught too.

What you see if one is stored: on a Page, the button renders with a dead `#` link; on a direct scan, the request returns a 404 rather than executing anything. A fallback URL using one of these schemes is discarded the same way. Ordinary app schemes such as `tel:`, `mailto:`, and `myapp://` are unaffected — those are [app links](/destinations/app-links) and are handled deliberately.

## Related

* [App Links & Fallback URLs](/destinations/app-links) — deep links, and what happens when the app isn't installed
* [Field Bindings & URL Templates](/destinations/field-bindings) — the `{{ }}` syntax and every available namespace
* [Direct Mode vs. Page Mode](/pages/direct-mode-vs-page-mode) — redirect straight to one Destination, or open a Page of them
