Referrals were a count and nothing more. Enlist recorded who referred whom, kept referral_count
accurate, and left what a referral was worth entirely to you — the docs suggested rendering
position - referral_count * 10 on your own confirmation page and picking the multiplier yourself.
That is now a waitlist setting.
Set referral_bonus on a waitlist — in settings, or with
PATCH /v1/waitlists/:id — and every signup on it gains a display_position:
display_position = max(1, position - referral_count * referral_bonus)It is null until you set a bonus, and equal to position for anyone who has referred nobody. The
max(1, …) is why it is computed rather than stored: with a large enough bonus the arithmetic runs
below one, and there is no position zero to show anybody. Set referral_bonus back to null to
turn it off, and display_position goes back to null with it.
position itself never moves. It comes from a monotonic per-waitlist counter, it is what
re-signing up returns, and it is what "who actually joined first" means. Letting referrals rewrite
it would make the queue a function of who last shared a link, and would mean the number a person
was shown last week could be wrong this week for a reason that has nothing to do with them. So
there are two numbers: one that records what happened, and one you show.
The dashboard signups table renders the effective position with base 47 underneath it whenever the
two differ, so a support question about someone's place has both numbers in front of you. It also
now shows how many signups arrived via a referral, and a per-signup referral count.
The MCP server's update_waitlist takes referralBonus alongside name, so an agent can set it
without dropping to the REST API. Omitting either leaves it alone; passing null clears the bonus.
Nothing changes for a waitlist that does not set a bonus. display_position is present in the API
response and in the SDK's Signup type either way — null when the feature is off — so reading it
is safe before you turn it on.