Sub-Affiliate Network

You open a network, share a join link, and approve the affiliates who ask to come in. Each approved partner is a Routy affiliate in their own right, with their own login and their own traffic source, promoting offers you published. Routy records the conversions their traffic produces against your network, you review them, and you generate a payout per period for each partner.

The commercial terms sit on the offer rather than on the partner. An offer carries the countries it covers, a currency, a start date and an optional end date, and its payout fields: CPA, CPC, CPL, a revenue-share percentage and a baseline. An offer can also be scoped to one partner, so a negotiated rate is a second offer rather than a per-partner override on the first.

Two things gate all of it. The partners feature has to be included in your plan, or every network endpoint answers 403. Reading the network screens needs the ListNetworks policy, and anything that changes it, from approving a partner to closing the network, needs EditNetwork.

• A public join link carrying your network id. A prospect opens it, signs in or registers, and the request arrives in your Issues panel as a partner_join_request with a notification. Nothing is automatic: you approve or reject each one, and the rejection reason you type is internal and not shown to them.
• A join page that can say who you are before anyone commits. GET /v1/networks/{networkId}/info returns your network name, programme name, website and logo to any signed-in caller, so a prospect can see who they're joining instead of a blank form.
• Offers with a visibility of Public or Partners, a list of ISO country codes (an empty list means every country), a currency, dates, and the four payout fields. Offers whose name is under three characters, or whose end date is in the past, are refused at creation.
• An access request per offer. An active partner asks for one with POST /v1/networks/{networkId}/offers/{offerId}/request-access, and you answer it with a decision of Approved or Rejected.
• A tracking link per offer, built by Routy from GET /v1/partners/offers/offer/{offerId}/url with whatever sub-ids and dynamic click parameters you pass in. That link is what you hand the partner.
• Postbacks per partner, each one a target URL and a conversion type id, with a test call so you can fire one before the first real conversion arrives.
• A conversion queue to review. Four types are recorded against a partner: signup, first-time deposit, CPA count and CPA commission. You can narrow it by partner, date range, status, conversion type, offer or brand link.
• Payouts generated for a period, each row carrying the conversion count, the calculated amount and the currency. Approve one with an amount override and notes, reject one with notes, or send a single decision for a list of payout ids.
• Partner-side views that are deliberately narrow. A partner reads their own payouts at GET /v1/partners/my/payouts and nothing else. Partner conversion rows are never visible to them, not even their own, because the row carries your offer terms and your economics.
• Network, partner and offer columns on your own clicks report, so a click that came in through a partner's link says which offer, partner and network it arrived from.

Opening the network and recruiting partners

Create the network with a name and, if you want one, a logo. The name has to be unique across Routy, case insensitive, so a name already taken by another network is refused. Routy generates a ten-character id for the network on creation.

The join link carries ?networkId=<your network id>. A signed-in affiliate who opens it goes straight to the join call. Someone without an account registers first, and for a new user the join only fires after they confirm their email address, so a registration that never gets confirmed never becomes a request. Joining your own network is refused and returns the OwnNetwork status, and for publishers that covers any affiliate they can act as, including collaborator grants, so the same person cannot sit on both sides of the partnership.

Each request creates a partner in Pending status and an account in New. The request shows up as an issue for the network owner, and you approve or reject it from there or through POST /v1/partners/join/approve. Approving flips the partner to Active and the account to Enabled; rejecting sets the partner Inactive and closes the account. Either way the partner is notified. A partner you rejected can ask again later, which puts them back into Pending rather than creating a second row.

Nothing is provisioned for a partner until you approve them. Their traffic source and their affiliate-program account are both created off the approval, and the traffic source is named after your network, as network: 'your network name'. Your partner quota is also checked at approval rather than at request, counted against your active partners, so a full plan never stops you from reading and reviewing the requests that are waiting. A plan with no partner allowance at all blocks approval outright.

Publishing offers and deciding who sees them

An offer's visibility is Public or Partners, and the offer list reads it: a partner listing offers with my=false sees only the offers marked Public or Partners, while my=true returns the offers they own. Offers also take a list of countries rather than a single one, which is also true of the commission plans behind them, so one offer covers a region instead of needing a copy per market.

Scoping an offer to a partner and leaving the rest Public is how a network runs a house rate alongside a negotiated one.

Reviewing a partner's conversions

Four conversion types are recorded for a partner, and only one of them is payable. The CPA commission carries the money, valued at whatever the offer's CPA says, and you can override that value at review time. Signups, first-time deposits and CPA counts are ordinary conversions with a count as their value, usually 1. Approving one of those sends it to the partner and adds nothing to any payout. An offer can also auto-approve its conversions, in which case they arrive Approved rather than Pending.

A review decision is explicit rather than implied: Approved, Rejected or Optimized. Statuses on the row are Pending, Approved, Rejected and Excluded.

Excluded now means one thing, which is that the offer was not valid for the conversion: the wrong brand, a country the offer does not cover, a date outside the offer's window, an offer or partner that is not active, or a CPA type with no CPA configured. A click whose brand does not match the offer's brand reports BrandNotMatched. Filtering to Excluded gives you the rows worth investigating and not much else. Approving an excluded row is still possible, and takes includeExcluded: true plus an explicit amount, because nothing on the row says what it should be worth.

Generating payouts

Payouts are generated per network for a period, and the per-network call requires the start and end to fall inside the same calendar month, so a period that straddles two months comes back as a 400. Generation runs in the background and hands you a task id to poll, since a network with a lot of partners takes a while.

A payout row records the period, the conversion count behind it, the calculated amount, the amount you approved, and who reviewed it and when, with your notes. The statuses are Pending, Approved and Rejected. There's no paid status and no payment rail, so Approved means approved for payment, and the transfer happens wherever you pay partners today.

Seeing partner traffic in your clicks report

A click that arrives through a partner's offer link carries the offer, and your clicks report resolves the chain from it: the network offer, the partner and the network, each with its id and its name, filterable, sortable and searchable by name.

Two limits are worth knowing before you build a report on these columns. They are populated on the ClickHouse reporting engine only, which is switched on per report and per affiliate, so on the older engine they come back empty. And they are sparse by design, because only a click carrying an offer populates them, which is roughly 0.2% of clicks across Routy. An offer with no partner on it leaves the partner column empty while the network column is set, so test the network column when you want to know whether a click belongs to a network at all.

Closing the network

When you stop taking new partners, close the network with POST /v1/networks/{networkId}/close. That sets its status to Inactive and keeps everything already in it. Closing a network that's already inactive returns a 400, so a second close is an error rather than a no-op.

Your own traffic has a ceiling, and it is made of the sources you can run and the hours you have. Recruiting partners earns you money on traffic you never bought: they run their own campaigns on your offers, Routy attributes the conversions to your network, and you keep the margin between what the advertiser pays you and the CPA you put on the offer. Both halves of that margin are numbers you set, on the offer.

The second reason is concentration. Affiliate income tends to sit on a few accounts and a few relationships, and any one of them can go away in a week without warning. Partners spread the same income across accounts you did not have to open.

The cost is review work, and it isn't small. Every join request is a manual decision. Conversions arrive as a queue someone has to work through unless you turn on auto-approval per offer, and payouts are generated, reviewed and approved per partner per period. If you want a network that runs itself, this isn't it. If you are already paying people for traffic and reconciling it in a spreadsheet, this moves the reconciliation to where the clicks are recorded.