Your referral accrual
Every launch the authenticated account has referred, and whether the referral-on-rails loop is currently configured to pay (§6.1 loop 4). **Owner-scoped.** The referrer is the bearer; there is no parameter that names another account, so this route cannot be asked for someone else's accrual. **There is no money field, and that is deliberate.** The plan fixes neither the share nor the period, so a response carrying an `earned` amount would be putting a guessed constant into a fee split. What is here is a count, a list, and `accruing` — a boolean about this deployment's configuration, not a claim that money has been earned or will be paid. `accruing: false` with a `referredCount` above zero is a normal, honest state: the referrals are recorded and paying nothing. Reading it is how a referrer knows the loop is not live for this deployment. `paidFromTreasury` is always `false`: paid from the rail, never from treasury up front.
Every launch the authenticated account has referred, and whether the referral-on-rails loop is currently configured to pay (§6.1 loop 4). Owner-scoped. The referrer is the bearer; there is no parameter that names another account, so this route cannot be asked for someone else's accrual. There is no money field, and that is deliberate. The plan fixes neither the share nor the period, so a response carrying an earned amount would be putting a guessed constant into a fee split. What is here is a count, a list, and accruing — a boolean about this deployment's configuration, not a claim that money has been earned or will be paid. accruing: false with a referredCount above zero is a normal, honest state: the referrals are recorded and paying nothing. Reading it is how a referrer knows the loop is not live for this deployment. paidFromTreasury is always false: paid from the rail, never from treasury up front.
Authorization
bearerAuth A bearer token. The Account routes accept a Privy access token; the MCP transport accepts an sk- API key issued by POST /account/api-keys.
In: header
Response Body
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/growth/referrals"{ "referrerId": "string", "referredCount": 0, "referrals": [ { "id": "string", "referrerId": "string", "launchId": "string", "chain": "ethereum", "token": "string", "shareBps": 0, "periodSeconds": 0, "paidFromTreasury": false, "createdAt": "string" } ], "accruing": true, "unavailableReason": "string", "shareBps": 0, "periodSeconds": 0, "paidFromTreasury": false}Remix a published showcase entry POST
Record that the authenticated caller has built on a published entry, and pay its author a credit grant from the existing credit ledger. **A bearer token is required**, and not only for the usual reasons: this call *moves credits* to another account. An unauthenticated POST that pays someone is a payout endpoint, so the loop is authenticated end to end. It succeeds only when the entry is published, its author has opted in as a remix template, and the caller is not the author. Every refusal answers 409 and **records nothing**: no remix row, no counter movement, no credit. That is what stops the public "remixed N times" number from being inflatable by anyone who can POST. How much the author earns is **configuration, not a constant** (`GROWTH_REMIX_AUTHOR_CREDITS`, in credits where 1 credit = $0.01), because the plan fixes no amount — it only says the author "earns credits". At the default of 0 the remix is still recorded and the author still sees who built on their work, but `creditsGranted` is `null` and no credits move, so the loop is wired without a number nobody agreed to. Set the variable and the same call pays. The record is written before the credit is granted. If the grant then fails, the remix stands (it happened) with its credit unmade and visible, which is recoverable; the other order could pay for a remix that never recorded, which is not.
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.