In-App Applications

Recruit affiliates from the users you already have, and link each one back to the app user they came from.

Your most motivated affiliates are often people already using your app. In-app applications let you invite them from inside the app itself, and record which app user became which affiliate — so you can show them their affiliate status, codes, and earnings without asking them to identify themselves twice.

Requirements

The Essential plan or above.
A subdomain for your project, which apply links are built on. Set it under Settings → General.
An affiliate group taking applications. Turning off a group’s form closes it to everyone, in your app and on the web alike.

There is nothing else to switch on: your app asks for an apply link when it wants one, so offering your users a way to apply is what turns this on.

How it works

Read a user. Their affiliate object is null, so they are not an affiliate with you yet — they are who you can offer to apply.

{
  "data": {
    "user": {
      "app_user_id": "user-1",
      "affiliate": null,
      ...
    }
  }
}

When the user asks to apply, request an apply link:

POST /users/:app_user_id/affiliate-apply-link
{ "group_slug": "creators" }

Omit group_slug to apply to your default affiliate group.

{
  "data": {
    "link": "https://appname.wwk.link/apply/creators?intent_token=v1..."
  }
}

Open the link. The user signs in or signs up, fills in your application form, and submits it.
Whoever completes it is linked back to the app user the link was built for.

From then on, every read of that user carries an affiliate object in place of the null — their status, their codes and code links, and their totals with you. Stop offering them the chance to apply and show their standing instead.

{
  "data": {
    "user": {
      "app_user_id": "user-1",
      "affiliate": {
        "id": "8fd0d4a2-1c1e-4f1c-9152-5297086a161c",
        "status": "approved",
        "codes": [
          {
            "code": "XYZ123",
            "code_link": "https://appname.wwk.link/XYZ123"
          }
        ],
        "stats": {
          "claims": 12,
          "conversions": 3,
          "earnings": 4200
        }
      },
      ...
    }
  }
}

The two states are mutually exclusive: a user can either apply or has already become an affiliate, never both, so that object is the only thing your app has to branch on.

Request the link when the user asks to apply, not ahead of time. It carries a short-lived token, so one exists only for someone who actually set out to apply.

The request is refused with FORBIDDEN.USER_CANNOT_APPLY_AS_AFFILIATE when your app is not on a qualifying plan, has no subdomain, or the user cannot apply — because they have an application pending, are already an affiliate, or are banned. The message says which. Users in any other standing can apply again, and are issued a link.

The group must exist and be taking applications, whether you name it or leave it to your default — a group_slug that matches nothing, or a group whose form is closed, is refused with NOT_FOUND.AFFILIATE_GROUP rather than handed back as a link that would go nowhere.

Reading a user’s affiliate standing

Once a user has become an affiliate, their User object carries an affiliate object. While it is null they are not an affiliate with you, which is your cue to offer them the chance to apply.

Field	Type	Meaning
`id`	string	The affiliate’s unique identifier. Stable, and the same across every app they work with.
`status`	string	Where they stand with you — see Statuses.
`codes`	array	The codes they can currently promote on your app, oldest first. Disabled codes are left out.
`codes[].code`	string	The code itself, as a user would enter it — for example `XYZ123`.
`codes[].code_link`	string \| null	The shareable link for that code. `null` when the affiliate’s group has code links turned off.
`stats`	object	Their totals on your app, and only your app — never summed across the other apps they promote.
`stats.claims`	integer	How many users have claimed one of their codes.
`stats.conversions`	integer	How many of those users went on to convert to premium.
`stats.earnings`	integer	Commission accrued all-time, in USD cents. Gross and cumulative — not a balance, not what they are owed, and not an amount available to withdraw, since payouts, holds and fees are settled separately.

Two things about codes worth designing around. An empty array is normal — nothing mints a code at approval, so an approved affiliate has none until they create one, and a deactivated or banned one has none any more. And the order is stable, oldest first, so a single share button can take the first entry and keep showing the same code.

Statuses

Status	Meaning
`pending`	Applied, awaiting your review.
`approved`	Active, and promoting your app.
`rejected`	Turned down. May apply again.
`withdrawn`	Withdrew their own application. May apply again.
`archived`	Set aside by you. Codes still work. May apply again.
`deactivated`	Switched off by you. Codes disabled. May apply again.
`banned`	Removed by you. Codes disabled, and terminal — they cannot apply again.

A deactivated or banned affiliate reports an empty codes array, since their codes are disabled.

Rules worth knowing

One app user, one affiliate. An app user can be linked to a single affiliate per app, and the first claim stands. If that user is already linked, a later application still goes through — it simply is not attributed.

They cannot claim their own code. An affiliate recruited from your app is still one of your users, so their own affiliate code is as reachable to them as anyone else’s. Claiming it is refused with FORBIDDEN.USER_CANNOT_CLAIM_OWN_CODE, the same as claiming their own referral code.

Each link is for one group. Ask for a separate link per group, passing its group_slug — which is how one app can offer several programmes, each leading somewhere different.