# Referral quickstart: Better Auth The code kept by your server, and each new user reported from an after-hook on sign-up. Referrals in an app on Better Auth: the code kept in a cookie by your server, each new user reported as a lead from an after-hook on sign-up, and sales from your billing system. ## Before you start - A key with the **Referral tracking** preset (the single scope `conversions:write`), made under **Settings, Developers**. Keep it on your server as `BOLTCLAW_API_KEY`, never in a browser or an app. - The program's id, on its **Setup** tab, as `BOLTCLAW_PROGRAM_ID`. ## 1. Put the tag on your site Add the version 2 tag to every page, in your root layout or template. It keeps a partner's code from `?via=

` in a first-party cookie on your own domain,
`bc_ref`, for the program's cookie window, and gives you
`BoltClawReferral.code()` in the browser.

```html

```

`data-payment-links="auto"` is only for Stripe Payment Links and the Buy Button;
`data-welcome="auto"` adds the friend's welcome. The tag makes no request at all
unless the welcome is on and the visitor arrived with a code.

## 2. Keep the code from your server

Set `bc_ref` in middleware as the [Next.js quickstart](https://boltclaw.ai/docs/referral-quickstart-nextjs)
or the [Express quickstart](https://boltclaw.ai/docs/referral-quickstart-express) shows.

**Why set the cookie from your server.** Safari deletes a cookie a script
created once the visitor has gone 7 days of browsing without using your site,
and keeps one only 24 hours on a page reached through a tracking link, so a
code the tag keeps can be gone a week later. A cookie your OWN server sets in
its response keeps its full lifetime, unless it comes through somebody else's
host (a third-party CNAME or IP address), which Safari caps at 7 days
(WebKit's published tracking prevention rules, read 2026-10-23). Setting `bc_ref`
from your server, not `HttpOnly`, keeps the full window and the tag still reads
it.

## 3. Report each new user as a lead

An `after` hook on the sign-up endpoints sees the new session and the request's
cookies.

```js
// auth.js
import { betterAuth } from "better-auth";
import { createAuthMiddleware } from "better-auth/api";
import { reportConversion } from "./referrals";

export const auth = betterAuth({
  // ...database, providers
  hooks: {
    after: createAuthMiddleware(async (ctx) => {
      if (!ctx.path.startsWith("/sign-up")) return;
      const user = ctx.context.newSession?.user;
      if (!user) return;
      const cookie = ctx.headers?.get("cookie") ?? "";
      const code = /(?:^|;\s*)bc_ref=([a-z0-9-]{3,40})/.exec(cookie)?.[1];
      await reportConversion({
        event: "lead",
        event_id: `signup-${user.id}`,
        customer: { id: user.id },
        referral: code ? { code } : undefined,
      });
    }),
  },
});
```

`reportConversion` is the helper from the Next.js quickstart. For social sign-in,
report the lead the first time a user is created instead (a database hook on
`user.create.after`).

## 4. Record sales

Connect the billing system you take payments with on the **Setup** tab (see
[Connect your billing system](https://boltclaw.ai/docs/referral-setup)), and pass the code to checkout
as its guide shows: sales, renewals and refunds are then reported for you, and
the setup status ticks them off. Not on one of the twelve? Report each sale from
your server with `event: "sale"`, your own `event_id` for the payment, the same
`customer.id` as the signup, `amount` in minor units and `currency`.

## 5. Send a test sale

Press **Send a test sale** on the Setup tab: a click, a signup, a sale with two
items and a partial refund go through your real rules as test data, credited to
the program's test partner, never paid and never counted. To check your own
wiring, send one of your own conversions with `"test": true`: it is test data
too, and **Clear test data** deletes it all. The setup status's rows turn green
only for live events.