Forwarding Query Parameters

By default, query parameters on a clicked link stay with Tolinku. They are recorded for analytics (UTM parameters show up in your campaign reports), but they are not passed along to wherever the user ends up.

Turn on Forward query params and Tolinku copies the query string from the clicked link onto the destination.

Turning it on

In the route form, find Forward query params under the fallback URL settings and switch it on. The setting is per route, so you can enable it for campaign links while leaving your other routes untouched.

It is off by default, and existing routes keep their current behavior until you enable it.

What it looks like

Your route has a fallback URL of https://shop.example.com/products. Someone clicks:

https://links.yourapp.com/promo?utm_source=newsletter&size=large

With forwarding off, they land on:

https://shop.example.com/products

With forwarding on, they land on:

https://shop.example.com/products?utm_source=newsletter&size=large

Where parameters are forwarded

Destination	Forwarded
Web fallback URL	Yes
Expired redirect URL	Yes
App deep link (yourapp://)	Yes
Deferred deep link after install	Yes
Buttons on a custom landing page	Yes
App Store URL	No
Play Store URL	No

Store URLs are deliberately left alone. Apple and Google control those URLs, and appending parameters to the Play Store link would overwrite the referrer value that deferred deep linking depends on.

Tip

Because forwarded parameters ride along on the deep link, your app receives them too. If a user clicks /promo?campaign=spring&size=large, your app opens with yourapp://promo?campaign=spring&size=large and can read both values. This works through an app install as well, so the parameters survive the trip to the store and back.

Collision rules

If the destination URL already has a parameter with the same name, the destination wins. A click cannot override what you configured on the route.

Given a fallback URL of https://shop.example.com/products?ref=tolinku&lang=en and a click on /promo?lang=de&size=large:

https://shop.example.com/products?ref=tolinku&lang=en&size=large

The incoming lang=de is dropped because the fallback URL already sets lang. The size=large is appended because nothing conflicts with it.

Which parameters are forwarded

All of them, exactly as they appeared on the clicked link, including UTM parameters. Nothing is filtered or rewritten.

Two limits apply as a safety measure. A maximum of 50 parameters are forwarded, and if the resulting query string would exceed 2,048 characters, the destination URL is used unchanged rather than truncated.

Custom landing pages

On a custom landing page, forwarded parameters are appended to the URLs on your button components, following the same collision rules. Store buttons are not affected.

Button URLs also support the {token} placeholder on dynamic routes. A button pointing at https://shop.example.com/p/{token} on a route clicked as /product/sku-123 renders as https://shop.example.com/p/sku-123.

Common uses

Campaign attribution end to end. Your marketing team appends UTM parameters to every shared link. With forwarding on, those parameters reach your website too, so the session shows up correctly in your own web analytics instead of appearing as direct traffic.

Passing context to your app. A link like /checkout?cart=abc123&coupon=SPRING gives your app both the cart ID and the coupon code when it opens, without you having to encode them into the token.

A/B and variant testing on your own site. Forward a variant=b parameter through to the fallback URL so your website can serve the matching experience for users who do not have the app.

Things to know

• Parameter values are URL-encoded when appended. A space becomes %20.
• Any fragment on the destination URL (#section) stays at the end where it belongs.
• Forwarding does not change what is recorded in analytics. UTM parameters are captured either way.
• The setting has no effect on links with no query string. There is nothing to forward.

Caution

Forwarded parameters come from whoever clicks the link, and anyone can add parameters to a URL before sharing it. Treat them as untrusted input in your app and on your website, the same way you would treat any other query string. The collision rule protects the parameters you configure on the route itself, but it does not validate the values that get appended.