The referral-on-rails loop's status
The configuration state of the referral-on-rails loop (§6.1 loop 4): whether it is switched on, the share and period it would pay, and — when it cannot run — exactly which piece is missing. **No bearer token is required.** These are deployment facts, not user data. The loop is **off by default** and the share and period are **both 0** by default, because the plan fixes neither a share nor a period. A non-null `unavailableReason` is the normal answer, not an error: it is the honest report of a loop whose economics have not been decided. `paidFromTreasury` is always `false`. The plan requires a referral to be paid from the rail and never from treasury up front, and the field is the literal `false` so the document carries that invariant rather than leaving it to prose. There is deliberately no `POST` here that records a referrer or pays one. Putting a guessed share into a live fee split is the thing §5.2 does not decide, so this module publishes the configuration the real loop will read and stops there.
The configuration state of the referral-on-rails loop (§6.1 loop 4): whether it is switched on, the share and period it would pay, and — when it cannot run — exactly which piece is missing. No bearer token is required. These are deployment facts, not user data. The loop is off by default and the share and period are both 0 by default, because the plan fixes neither a share nor a period. A non-null unavailableReason is the normal answer, not an error: it is the honest report of a loop whose economics have not been decided. paidFromTreasury is always false. The plan requires a referral to be paid from the rail and never from treasury up front, and the field is the literal false so the document carries that invariant rather than leaving it to prose. There is deliberately no POST here that records a referrer or pays one. Putting a guessed share into a live fee split is the thing §5.2 does not decide, so this module publishes the configuration the real loop will read and stops there.
Response Body
application/json
application/json
application/json
curl -X GET "https://example.com/growth/referral"{ "enabled": true, "shareBps": 0, "periodSeconds": 0, "unavailableReason": "string", "paidFromTreasury": false}Record that you referred a launch POST
Attach the authenticated account to a launch as its referrer (§6.1 loop 4). **The referrer is always the caller.** The body carries a launch, never a referrer, so there is no request this route accepts that records a referral against another account. The referral is **idempotent on `(referrer, launch)`**: recording the same pair again updates the existing row rather than adding a second one, because a double-counted referral is a referrer who would be paid twice for one thing. **The share and period recorded are the ones configured right now**, and both are `0` when the deployment has not set them — which is the default. That is honest rather than a loss: the fact this route exists to capture is *who referred which launch*, and that does not change when the economics are decided. Setting the share later does not require referrers to re-attach themselves. `paidFromTreasury` is always `false`: a referral is paid from the rail, never from treasury up front. This route records nothing about money. It is not a payout endpoint and it does not move credits.
The public showcase listing GET
Every **published** showcase entry, newest publication first. **No bearer token is required** — a showcase anyone can read is the whole point of the public artifact loop (§6.1 loop 1). Only entries whose creator opted in appear. A draft, a withdrawn entry, and a foreign entry are all absent, and their absence is indistinguishable: this route has no owner dimension, so it cannot reveal that a particular person has unpublished work. The `total` field counts everything matching the filter, not the page, so a client can tell "that is all of them" from "that is the first page".