Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/org-quicko/linq/llms.txt

Use this file to discover all available pages before exploring further.

A dynamic link is a standard redirect link with one or more conditional Rules attached. When a visitor hits the short URL, linq evaluates the rules in order and redirects to the first destination whose conditions all hold. If no rule matches, the link’s own default destination is used as a fallback. This lets a single short URL serve different destinations to different audiences — all without any server-side logic on your end.

​
How Rules Work

Rules are evaluated synchronously inside the redirect handler, before the 302 is issued. No external calls are made during rule matching.
1

Rules are ordered by position

Each rule has a position field assigned by the server (derived from the array index in the request body). Lower positions are checked first.
2

All conditions in a rule must hold (AND)

A rule can carry up to 10 conditions. Every condition in the rule must evaluate to true for that rule to win. There is no OR logic within a single rule — use separate rules for that.
3

First matching rule wins

The moment a rule’s conditions all hold, its destination is used and evaluation stops. Subsequent rules are not checked.
4

Default destination is the fallback

If no rule matches — or if the link has no rules at all — the redirect goes to the link’s own destination.
Rule matching is synchronous and in-process — it happens entirely inside the redirect hot path with no external calls, no database reads beyond what was already fetched for the link, and no added latency beyond a few microseconds of CPU.

​
Condition Types

Every condition is one of two discriminated types, defined by a type field.

​
platform

Matches the visitor’s platform as detected from the User-Agent header.
​
type
"platform"
required
Discriminator value.
​
value
"android" | "ios" | "desktop"
required
The platform to match against. android and ios are detected from mobile User-Agents; everything else resolves to desktop.

​
query_param

Matches a key (and optionally a specific value) in the visitor’s incoming query string.
​
type
"query_param"
required
Discriminator value.
​
key
string
required
The query parameter key to look for. Case-sensitive. Up to 64 characters.
​
value
string
Optional. When omitted, the condition is satisfied if the key is present with any value (including an empty string). When provided, the condition is satisfied only if the key is present with exactly this value. Up to 512 characters.

​
Rule Fields

A rule as returned by the API:
​
id
string (UUID)
Unique identifier for this rule row.
​
link_id
string (UUID)
The link this rule belongs to.
​
position
integer
Server-assigned evaluation order. Zero-indexed. The lowest matching position wins. Controlled entirely by the array order you send to PUT /api/v1/links/{id}/rules.
​
destination
string (URI)
The URL visitors are sent to when this rule matches.
​
conditions
Condition[]
Array of 1–10 conditions. All must hold for the rule to match (AND logic). A rule with zero conditions is rejected at write time.

​
Managing Rules via the API

Rules are a sub-resource of a link. The full set is replaced atomically in one request — there is no partial update.
MethodEndpointDescription
GET/api/v1/links/{id}/rulesRead the current rules in position order.
PUT/api/v1/links/{id}/rulesReplace the entire set. Send [] to remove all rules. Requires editor role or above.
The PUT body is an ordered array of rule inputs. The server assigns position from the array index, so the order you send is the order they are evaluated. 
PUT /api/v1/links/{id}/rules
[
  {
    "destination": "https://apps.apple.com/app/example/id123456789",
    "conditions": [
      { "type": "platform", "value": "ios" }
    ]
  },
  {
    "destination": "https://play.google.com/store/apps/details?id=com.example.app",
    "conditions": [
      { "type": "platform", "value": "android" }
    ]
  }
]
You can also set rules at link creation time by including a rules array in POST /api/v1/links. This is equivalent to creating the link and then calling PUT /api/v1/links/{id}/rules in one transaction.

​
Example: Mobile Deep-Linking

A common use case is sending mobile users to the relevant app store while desktop users land on the web product page. 
// Rules for link with destination: https://example.com (desktop fallback)
[
  {
    "destination": "https://apps.apple.com/app/example/id123456789",
    "conditions": [
      { "type": "platform", "value": "ios" }
    ]
  },
  {
    "destination": "https://play.google.com/store/apps/details?id=com.example.app",
    "conditions": [
      { "type": "platform", "value": "android" }
    ]
  }
]
With these rules attached, visiting the short URL:
  • On iOS → redirects to the App Store listing
  • On Android → redirects to the Google Play listing
  • On desktop (or any undetected platform) → redirects to the link’s own destination (https://example.com)

​
Example: Query Parameter Routing

Route visitors based on UTM parameters or feature flags already present in their session. 
// Send beta users to a separate landing page
[
  {
    "destination": "https://beta.example.com/landing",
    "conditions": [
      { "type": "query_param", "key": "beta", "value": "1" }
    ]
  },
  {
    "destination": "https://beta.example.com/landing",
    "conditions": [
      { "type": "query_param", "key": "preview" }
    ]
  }
]
The second rule matches any visitor who has a preview key in their query string, regardless of its value.

​
Example: Combining Conditions

Multiple conditions in a single rule are ANDed together: 
// iOS users who came from the newsletter
[
  {
    "destination": "https://apps.apple.com/app/example/id123456789",
    "conditions": [
      { "type": "platform", "value": "ios" },
      { "type": "query_param", "key": "utm_medium", "value": "email" }
    ]
  }
]
This rule only matches a visitor who is both on iOS and has utm_medium=email in their query string. An iOS visitor without that parameter falls through to the next rule or the default destination.

​
Use Cases

App store deep-linking

One short URL in your bio or print ad automatically routes iOS users to the App Store, Android users to Play Store, and desktop visitors to your web app.

UTM-based personalization

Route visitors from different campaigns to different landing pages based on UTM parameters, without maintaining separate short URLs per campaign.

A/B testing

Use a query parameter flag to split traffic between two destinations. Combine with forward_query: true so downstream analytics tools see the full query string.

Gated content

Gate a destination behind a query parameter check — for example, a token set by your email platform — without adding server-side redirect logic.

Build docs developers (and LLMs) love

Get started for freeTalk to us