Skip to content

Affiliate programs

Not implemented

No part of this works yet — the gateway route is live, but no bot token can be issued, so no method can be called. See implementation status.

Commissions depend on an undecided currency

An affiliate program pays a percentage of purchases. On GROM, what a purchase is denominated in has not been decided — the specification references Telegram-style Stars while GROM's own internal token is called Take, and the two have not been reconciled. No payment provider is connected.

Everything downstream of that inherits the uncertainty: what a commission is paid in, when it settles, whether it can be withdrawn, and what the platform's own cut is. This page describes attribution — which is the part that does not depend on the currency — and declines to state the payout mechanics, because they have not been chosen.

Read Payments first. Do not offer anyone a commission rate.

Specified in outline only

Affiliate programs are B20 in the project TZ, at priority P3 — the lowest tier, behind everything else on this site. The entry is a short list of requirements and four endpoint names. There is no schema, no payout model, and no implementation.

The model

A Mini App owner opens an affiliate program. Other people — content creators, channel owners, ordinary users — promote the app, and earn a share of what the users they brought in spend.

Three parties, and it is worth naming them because the endpoint names are terse:

  • The app owner, who defines the program and pays out of their revenue.
  • The affiliate, who promotes the app and collects a share.
  • The user, who arrives through a link and, eventually, buys something.

Program parameters

Per the outline, a program is defined by:

ParameterMeaning
commission_permilleThe affiliate's share, in parts per thousand rather than per cent — so a value of 50 means 5%. Per-mille gives finer granularity than integer percentages.
duration_monthsHow long attribution lasts after the first touch.
enabled stateWhether the program is currently accepting new affiliates.

Whether these values can be changed after affiliates have joined — and what happens to already-attributed users if they are — is not specified.

Attribution: first touch, time limited

Each affiliate gets a unique link:

https://code.casinoplaneta.info/<botname>?startapp=ref_<affiliate_id>

This is an ordinary deep link carrying a startapp parameter. When a user opens the app through it, the affiliate is attributed.

The two rules that determine who gets paid:

First touch wins. The first affiliate a user arrives through is the one credited. A user who later clicks a different affiliate's link does not re-attribute — the second affiliate gets nothing for that user. This is the opposite of last-touch attribution used by most web ad systems, and it changes affiliate strategy substantially: the value is in reaching people who have never opened the app, not in being the last link before a purchase.

Attribution expires. It holds for duration_months from the first touch, then stops. Purchases after that window earn nothing.

Deep links do not open the app yet

The code.casinoplaneta.info association file is published, but the Android app does not claim these links, so they open in a browser rather than in GROM. Referral links would not currently reach the app even if the rest of this existed. Status has the detail.

Endpoints

The TZ names four, without signatures or payloads:

EndpointPurpose
connectStarRefBotAn affiliate joins a program and gets their link
getSuggestedStarRefBotsPrograms an affiliate could join
getConnectedStarRefBotsPrograms an affiliate has already joined
editConnectedStarRefBotChange or end an existing connection

These are MTProto-style names inherited from the reference platform, and GROM has no MTProto layer — see MTProto. Whether they surface as HTTP Bot API methods, as client-only calls, or not at all is unresolved. They are not in the method reference because there is nothing to document beyond a name.

Reporting

The outline calls for the app owner to see: users acquired, total revenue attributed, and commission paid.

What it does not define — and what you would need before running a real program — is who can dispute a figure, how a chargeback or refund unwinds a commission already credited, and what an affiliate sees about the users they brought in. That last one is a privacy question, not just a product one: an affiliate learning which specific people they referred, and what those people bought, is a different system from one that shows only aggregates.

If you were planning to build on this

Be blunt with yourself about the dependency chain. An affiliate program requires:

  1. A working Bot API gateway — route live, but no bot token can be issued yet.
  2. Mini Apps — specified only.
  3. Working payments — not implemented, currency undecided.
  4. Deep links that open the app — half connected.
  5. Affiliate programs themselves — P3 outline, four endpoint names.

Each of those has to land, roughly in that order, before this becomes real. There is no schedule for any of them.

The transferable work is offline: deciding what a fair commission is for your economics, and how you would detect self-referral and fraud. Both are worth thinking about early and neither needs an API. Everything requiring a call to this platform is blocked on all five items above.