Referrals and rewards

RIP.BET has referral and reward surfaces for users. Exact program terms can change, so clients should display values returned by the API rather than hard-coding rates, caps, or payout dates.

Resolve a code

curl -s "{API_BASE_URL}/v1/referrals/resolve?code=SAM"

Use this before showing who owns a referral code.

Create or read your codes

curl -s "{API_BASE_URL}/v1/referrals/code" \
  -H "Authorization: Bearer $JWT"

curl -s -X POST "{API_BASE_URL}/v1/referrals/code" \
  -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{"code":"SAM"}'

Set a referral relationship

curl -s -X POST "{API_BASE_URL}/v1/referrals/intent" \
  -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{"code":"SAM"}'

Treat referral relationships as durable once accepted. Do not build a UI that implies users can freely switch referrers unless the API says so.

Read referral state

curl -s "{API_BASE_URL}/v1/referrals/tree" \
  -H "Authorization: Bearer $JWT"

curl -s "{API_BASE_URL}/v1/referrals/payouts?limit=20&offset=0" \
  -H "Authorization: Bearer $JWT"

Rewards

curl -s "{API_BASE_URL}/v1/rewards/0xabc..."

Use the returned numbers and labels as display data. Avoid describing unconfirmed reward schedules, maker tiers, cashback rates, or payout timing in client copy.

Legacy endpoint

POST /v1/referrals is legacy. In environments using the newer referral system, it returns 410 Gone.