conditional redirects.

how rules evaluate.

every link can have a list of redirect rules. each rule has a priority, a set of filters (territory, OS, device, channel, date window), and a destination URL. on every fan tap, the edge worker:

• looks up the link config in cloudflare KV.
• parses the request — country (from cloudflare’s geo), OS + device + browser (from the user-agent), referring channel (from ?c=tiktok if present, otherwise host-detected from referrer).
• walks rules in priority order; first match wins. issues a 302 to that rule’s destination URL.
• if no rule matches, falls back to the default destination — or the landing page (which is its own kind of destination).

three ways to author rules.

the destinations tab → redirects sub-tab has three modes:

• templates (default) — prefab patterns for the most common cases. click one, fill in the destination URL, done.
• auto-suggest — generates rules from your scanned destinations. e.g. if your release is on apple music and you’re a US artist, it suggests “US fans → apple music, everyone else → landing.” you can apply or edit.
• custom — raw editor. pick filters, pick a destination, set priority, save.

the templates.

the prefab patterns we ship with:

• native app — fans on iOS/android get the deep link to the spotify or apple music app; everyone else gets the landing.
• territory split — US fans go to one URL, EU to another, ROW to the landing. classic distributor pattern.
• tiktok funnel — anyone from tiktok goes to a dedicated landing variant or a presave URL. handy for dance-moment singles.
• release-day window — between two dates fans go to the pre-save flow; outside the window they land normally.
• device-specific — mobile fans get the shorter mobile-optimized destination, desktop fans get a richer landing page.

what filters you can pick.

every rule is a conjunction (AND) of any of these:

• territory — ISO country code (US, GB, IL, DE...). evaluated from cloudflare’s edge geo, ~99.5% accurate at country level.
• OS — ios / android / mac / windows / linux. parsed from the user-agent.
• device — mobile / tablet / desktop. parsed from the user-agent (not user-controllable but reliable).
• referrer / channel — twitter / instagram / tiktok / etc. via ?c= on the short URL, or auto-detected from the referer header.
• date window — from-date and/or to-date in UTC. handy for release-day windows.

the simulator.

below the rule list, every link has a simulator. type in a fake fan profile (US, ios, mobile, tiktok, today), and the simulator tells you:

• which rule (if any) matches first.
• which destination they’d be sent to.
• whether the landing page would render at all.

we run the same evaluation logic the edge worker runs, so the simulator’s answer is the answer. tweak rules, re- simulate, ship.

via the API.

every redirect endpoint is on the public API. example: add a rule via curl —

curl -X POST https://api.yala.la/v1/links/{linkId}/redirects \
  -H "authorization: Bearer yla_live_..." \
  -H "content-type: application/json" \
  -d '{
    "priority": 1,
    "filters": {
      "territory": ["US", "CA"],
      "device": ["mobile"]
    },
    "destinationUrl": "https://music.apple.com/album/...",
    "enabled": true
  }'