Routy

September 2026

1 new feature, 1 new integration, 17 improvements, 10 fixes and 21 connector fixes.

New1

  • NewTracking links

    Short links.

    You can now turn any of your tracking links into a short address — https://go.yourbrand.com/s/1A7kP9mQ2x4f — instead of the ~150-character URL we generate today. It is the same tracking: same destination, same traffic source, the sub-ids and campaign you baked in, and the clicks land in your normal reports. Made for the places a long URL cannot go: SMS, QR codes, bio links, print. You can create them one at a time or thousands at once, they work the instant they exist, and you can change where one points or expire it after it has been published — the address itself never changes, because it is already out there. We pick the shortest address your account can use — ask for the list and you can choose a different one, including your own domain when you have one, so a link you send can carry your name rather than a host shared with everyone else. ⚠️ The address is part of the link: it is fixed once the link exists, and the link only works on the address it was issued on. That is deliberate — it stops a link you sent from a domain of your own being served from somewhere else. The tracking you set when you created the link is what gets recorded, always — you hand these links to other people, so the parameters that say who the link belongs to and how the click is reported (PA, PB, cid, camp and the rest) are ignored if someone adds them to the address and cannot rewrite your reporting. Your own parameters, such as utm_source, still pass through as sent, which is where to put something you want to vary per send. Testing and debugging work exactly as on any other Routy link, per visit. A short link cannot be permanently set to a diagnostic mode, because a link fixed to it would never redirect a single recipient. Short links are part of your plan — if yours does not include them, creating one is refused with a plan-limit message. A short link always points at one of your own links; it is not a general URL shortener, deliberately. Guide

    Read the full page

New integrations1

  • IntegrationAccount integrations

    New: Rewards Affiliates.

    You can now connect a Rewards Affiliates publisher account and have your casino figures collected automatically, using the same username and password you sign in to the portal with - there is no API key to request and nothing to switch on at their end. You get daily figures for every casino brand you promote (clicks, registrations, new bettors, betting players, gross win, bonus money, casino profit and your earnings), plus a monthly breakdown by campaign tag. Campaign figures are monthly rather than daily because that is the only way the Rewards Affiliates portal publishes them; your brand and day figures arrive daily as normal. See the setup guide.

Improved17

  • ImprovedTracking links

    A retired link that still gets clicks is now a warning, not a critical alert.

    Retiring a link is something you chose to do, so being told about it in the same red as a quota outage was wrong. There are now two separate issues: "Clicks blocked: link no longer in use" (a warning — the link was retired on purpose and a placement somewhere still points at it) and "Clicks blocked: link inactive" (now an error rather than critical — a link that is supposed to be working and is not). Existing open alerts for inactive links have been moved down to error too.

  • ImprovedTracking links

    Why a blocked link shows no clicks.

    If you open the clicks log for a link that a "clicks blocked" issue is complaining about, you will find nothing there — and that is correct, not a second fault. A blocked click is turned away before it is recorded, so no click is ever logged. Use the issue's own details instead: it carries the URL that was turned away, the page the click came from, the referrer, and your pa/pb parameters, which is what locates the placement that needs updating.

  • ImprovedAccount integrations

    The same check now covers tracker reports.

    A tracker-level report with no tracker column has the same problem — nothing in it can be attributed — and now says so instead of silently producing empty figures.

    Read the full page
  • ImprovedAccount integrations

    These integration alerts clear themselves once the problem is fixed.

    Previously nothing closed them but a timeout, so they lingered long after the setup behind them was corrected. They now close once a collection shows the problem gone. An alert still showing means the problem is still there, which is what it should have meant all along.

  • ImprovedAccount integrations

    Buffalo: a run that keeps being refused now backs off instead of making it worse.

    We retry a refused request more patiently than before, wait as long as the brand asks us to when it says so, and if the brand is clearly over its limit we stop that run rather than spending minutes hammering it. The dates left uncollected come back on the next cycle.

    Read the full page
  • ImprovedAccount integrations

    Buffalo: an option to pull a whole date range in one request.

    Where a brand supports it, a month's data can now be fetched in one request per feed instead of one per day — thirty times fewer requests, which is the surest way to stay under a brand's limit and makes backfills much faster. It is off by default and support will turn it on per account after checking the brand returns the full range; if a brand turns out not to, we fall back to day-by-day automatically and nothing is lost.

    Read the full page
  • ImprovedAccount integrations

    ReferOn: a new "Affiliate scope" setting, for accounts with sub-affiliates.

    If your ReferOn login owns sub-affiliates, some brands may exist only under those — and we pull the account you log in with, on its own. That stays the default and is almost always right, because each sub-affiliate should be connected to Routy as an account in its own right. The new setting lets that be changed to All affiliates, which pulls the login plus everything beneath it. Only use it if those sub-affiliates are not connected separately — otherwise their traffic arrives twice and your numbers will be overstated. If a brand is missing from your reports, the usual answer is that the sub-affiliate carrying it needs connecting, not this setting; ask support and we can tell you which one it is. Changing the setting does not backfill — the affected dates need re-pulling.

    Read the full page
  • ImprovedAccount integrations

    ReferOn: report grouping, measures and page size are now editable settings.

    The dimensions each report is grouped by, the measures pulled, and how many rows are fetched per request were always configurable but had no screen — they are now proper settings with descriptions. Anything already configured on your accounts keeps working unchanged.

    Read the full page
  • ImprovedAccount integrations

    IncomeAccess: you can now choose which report your figures come from.

    Our default report, Earnings, carries revenue and commission in detail — but it carries no acquisition figures at all: no registrations, no first deposits, no active player counts. If those are missing from your IncomeAccess reporting, that is why. A new Tracker report setting lets the account be pointed at a report that includes them, along with a Tracker group by setting for how the figures are broken down. "Member Report - Detailed Aggregate" is usually the one to pick — it adds the acquisition figures while keeping the per-site and per-tracker breakdown you have now. "Quick Summary" carries the same figures but only as a single daily total per brand, with no site or tracker detail, so choose it only if that is what you want. Accounts left alone keep the exact behaviour they have today. Changing the setting does not backfill — ask support to re-run any dates you want re-collected under the new report.

    Read the full page
  • ImprovedAccount integrations

    Collections are now spread across the hour instead of all starting at once.

    Every account on the same schedule used to become due at the exact same second, so a network could receive our whole estate's requests in one spike — and networks respond to a spike by slowing down or not answering, which is how a collection ends up failing for a reason that has nothing to do with your account. Each account now starts a few minutes into its window rather than exactly on it. Nothing needs changing and the schedule you set still applies — a collection set for 02:00 still happens in the 02:00 hour, just not at 02:00:00 to the second. You may see one cycle land later than usual as this settles in.

    Read the full page
  • ImprovedAccount integrations

    You're now told when a partner doesn't share click-level data for an account.

    Some partners only send the report that ties each registration and deposit to the click behind it once your affiliate manager there switches it on. Without that report, conversions on the account show in your totals but can't be credited to your links, campaigns or traffic sources. We used to notice this quietly and tell nobody. It's now an alert on the account, with an email, and it names the two fixes: ask your affiliate manager at the partner to enable dynamic-tag (click-level) reporting, or set up a postback. The alert closes by itself on the first collection after the report is enabled. Daily totals are unaffected either way. It covers Affilka-based partners for now. See Click-level data not available.

    Read the full page
  • ImprovedConversion webhooks

    Your traffic source's own click ID and your sub-IDs can now go in the URL.

    ${externalClickId}, ${parameterA}, ${parameterB}, ${gclid}, ${fbclid}, ${msclkid} and ${obclid} were unreachable before; they are the values most postbacks actually need. Values are now encoded for a URL properly as well — a name like "Acme & Co" used to break the address, and now arrives intact.

    Read the full page
  • ImprovedConversion webhooks

    A broken webhook URL now tells you, instead of failing quietly.

    If a placeholder in your webhook's URL is mistyped — a dot or a space inside it, or a name that isn't one of ours — you used to find out only when your tracker stopped seeing conversions. Now the webhook won't save until it's right, and the message names the placeholder at fault. Webhooks saved before this raise a "Webhook URL Is Invalid" alert, by email too, saying whether postbacks have stopped or are arriving with a value missing. Fix the URL and the conversions that couldn't be sent in the meantime go out automatically over the following days — no need to resend them.

    Read the full page
  • ImprovedConversion webhooks

    Webhook delivery alerts clear themselves as soon as delivery works again.

    When your server was down or refusing postbacks, the alert stayed up for a day after the last failure. It now closes on the next postback your server accepts, so an alert still showing means it is still failing.

    Read the full page
  • ImprovedPlans & usage

    Limits on postbacks, page views and outgoing webhooks now apply to your live usage.

    They were checked against a figure that could be up to two hours old, so activity past your limit could keep flowing for a while before it stopped. They now take effect when the limit is actually passed. If you run close to your limits you may notice them apply sooner than before — upgrading ahead of the limit avoids any gap in tracking. Clicks are still never refused because of a limit. See how your usage is measured.

  • ImprovedPlans & usage

    You are now warned as your shared event allowance fills.

    Plans that limit events overall, rather than each activity type, used to give no warning at all before that allowance ran out.

  • ImprovedAlerts & notifications

    Slack alerts now say which account they are about, by name.

    If you send Routy alerts to a Slack channel, the card identified the account by its internal number only. It now reads the account name alongside that number. Nothing about which alerts you receive, or where they go, has changed.

    Read the full page

Fixed10

  • FixedTracking links

    Some clicks were failing outright instead of redirecting.

    A visitor arriving on a tracking link whose browser (or the page sending them) supplied a malformed referrer was shown an error page instead of being sent to the destination, and that click was not recorded at all — so the traffic was lost twice over, once for the visitor and once from your reports. This affected regular links, offer links and cloaked links alike. An unusable referrer is now simply treated as "no referrer" and the click redirects and records normally. If you have seen unexplained gaps between your own traffic figures and your Routy click counts, this is one cause. The fix applies to clicks from now on; clicks already lost cannot be recovered.

  • FixedTracking links

    Replacing a link quietly threw away its traffic.

    When you replaced a tracking link, we created the new link and retired the old one — but never recorded which link had replaced it. Clicks still arriving on the old link had nowhere to be forwarded to, so they were turned away instead of being sent on to the replacement. Replacing a link now stores that connection, and clicks on a replaced link are forwarded to whatever superseded it, following the chain if it has been replaced more than once. Links replaced before this fix have no replacement recorded and cannot be recovered automatically — open the retired link and point it at its replacement, and its traffic starts flowing again.

  • FixedTracking links

    A link that has been deleted now says so, instead of showing a server error.

    Someone clicking one of your tracking links after you deleted it used to get a bare "Internal Server Error" message, which looked like Routy was down. They now see a plain page saying the link is no longer available and may have been removed. The link still doesn't redirect anywhere, since there's nothing left to send the click to. If you deleted a link that is still placed somewhere, update or remove that placement. The same page now appears for any tracking link that can't redirect in a visitor's browser (an inactive link, a closed traffic source and so on), replacing the raw error text they used to see.

  • FixedGetting started

    The questions we ask when you sign up are now actually kept.

    The short questionnaire after signup — company size, brands, traffic, media, industry — was being collected and then discarded before it reached your account. Your answers are now stored with your account, so your account manager can see what kind of publisher you are before your first conversation instead of asking you again. Nothing changes in how the questionnaire looks or behaves, and skipping it still costs you nothing. The answers are visible to Routy staff only, never to other publishers or partners. There is no screen showing your own answers back to you — if you want to see, change or remove them, ask your account manager or support. Answers given before this change were not kept and cannot be recovered.

  • FixedTracking pixel

    The pixel was adding its tracking parameter to every link on the page, not just your tracked ones.

    The pixel decides which links to tag by matching them against a list of patterns. One pattern in that list had a stray separator character on the end, which quietly turned it into "match everything" — so internal navigation, social buttons and unrelated outbound links were all rewritten with a tracking id, and a page view was recorded on every page rather than only on pages carrying a tracked link. This affected sites across the platform, not a single account, and it did not break tracking — matched links were still tracked correctly and your click and conversion figures are unaffected. What it did was decorate links that should have been left alone, and inflate page-view counts. The pixel now ignores any pattern that would match every link, so this corrects itself as soon as the updated pixel is served; nothing needs changing on your site. If your page-view figures drop after this, that is the inflation going away, not traffic being lost.

    Read the full page
  • FixedTracking pixel

    Page views were not being recorded on most of your pages.

    The pixel only records a page view on pages that carry at least one of your tracked links — but it was checking only the first 50 links on the page before deciding, and on a site with a normal-sized menu the first tracked link usually falls well past that. So on those pages nothing was recorded at all, while the links themselves were still tagged correctly. Your clicks, conversions and commissions are unaffected — those are counted when a link is clicked, not when a page is viewed. What was affected is page-view reporting: the figures for the period are an under-count, and they do not reflect a drop in real traffic. This corrects itself as soon as the updated pixel is served; nothing needs changing on your site. Expect page-view figures to rise afterwards — and note this runs the opposite way to the tagging fix above, which removed page views that should never have been counted.

    Read the full page
  • FixedReports

    Searching a conversion by click id is no longer slow — and now respects the dates you picked.

    Pasting a click id into the search box on the conversions report took six seconds or more, and got slower the longer your account had been with us, because the search quietly ignored the date range on screen and looked through your entire history every time. It now searches the period you are looking at, which returns in well under a second. If a click id returns nothing, widen the date range — the conversion is outside the period currently selected.

    Read the full page
  • FixedPlans & usage

    Usage warnings could show impossible figures.

    A warning about your account limit or an activity limit could report numbers that bore no relation to your plan — well over 300% of a limit you had never reached — because it compared a running total that never reset against a limit from a plan you were no longer on. Warnings now use your current plan and this billing period's usage, and your account limit is measured against the accounts you have right now, so closing an account frees its place. Nothing was blocked by the wrong figures — they only ever affected the warning.

  • FixedPartners & networks

    Approving a blocked signup or first-time deposit asked you to pay for it.

    A partner conversion is one of four kinds, and only one of them is money — a CPA commission. A signup, a first-time deposit and a CPA count are signals: they record what the partner's traffic produced, they carry a count rather than an amount, and they are never paid. When one of those was blocked by the offer's terms (wrong country, offer not running yet, no rate configured) and you chose to send it to the partner anyway, the dialog demanded a payout value and would not proceed without one — so you had to invent a figure for something that is not worth anything, and we then recorded that figure on the conversion as though it were owed. Nobody was overpaid: a signup never enters a payout whatever value it carries. What it did was show an amount on a row that never earned one, including on the conversion the partner receives. Approving a blocked signup, first-time deposit or CPA count now asks for nothing at all — you just confirm the override. Approving a blocked CPA commission still asks for the value, and still requires it, because that one really is money and a blocked commission has no amount of its own. Overriding a block is still one conversion at a time with an explicit confirmation, for every kind. Rows that already carry an invented value are not corrected automatically — ask support if any need clearing.

    Read the full page
  • FixedAlerts & notifications

    Some "Clicks Blocked: Invalid Traffic Source" alerts were false.

    If a visitor closed their browser (or their connection dropped) partway through a click, we could mistake that for your traffic source being missing or wrong — and send you a critical alert, by email, about a traffic source that was working perfectly. The alert then stayed open for three days. Nothing was wrong with the link, the traffic source or the click in these cases. We now tell the difference between "this traffic source does not exist" and "we could not check", and only the first is reported to you. Genuine blocked-click alerts are unchanged and still arrive as before. If you dismissed one of these alerts as inexplicable, that was why — and if one is still showing against a traffic source you know is fine, it will clear on its own.

Maintenance

Connector reliability: 21 fixes across account integrations and connected channels.