# Docs

- Platform: Using RefRef

  - **Getting Started**
  - [Overview and quickstart](/docs/platform): What RefRef does today, how Sandbox and Live Projects work, and the first steps from a new Program to a tested referral.
  - [Concepts and glossary](/docs/platform/glossary): The RefRef model in one page — Workspaces, Projects, Programs, participants, referrals, Events, benefit rules, Rewards, and partners.

  - **Set Up**
  - [Workspaces](/docs/platform/workspaces): Your company account in RefRef - members and roles, what owners and admins can do, API keys, and switching between Workspaces.
  - [Projects](/docs/platform/projects): Create a Project, use its Sandbox and Live twins, find its credentials, and set its referral events, custom units, and integrations.
  - [Programs and settings](/docs/platform/programs): Create a referral, affiliate, or loyalty Program from a template, write its reward rules and terms, design its Widget, and choose its delivery, payout, referee offer, and partner settings.
  - [Participants and enrollment](/docs/platform/participants): Name your customers with your own IDs, register their details, rename them, enroll them in Programs, and give them referral codes and links.
  - [Events and qualifying event types](/docs/platform/qualifying-events): The Event types that RefRef accepts, which types can create a referral, how to send signups, purchases, custom Events, subscriptions, and refunds, and how RefRef decides each Event.
  - [Rewards and delivery](/docs/platform/rewards): How a Reward is earned, how each delivery method works, the delivery statuses, cash payouts, refunds, and voids.
  - [Partners](/docs/platform/partners): Invite partners by email or accept their applications, publish a join page, and what partners see in the Partner app.
  - [Webhooks](/docs/platform/webhooks): The RefRef event catalog, how to receive and verify webhook events, read the event feed, and confirm Rewards.
  - [Connect an AI assistant with MCP](/docs/platform/mcp): Connect an MCP client to RefRef with your Console login, choose the Workspaces and Projects it can reach, and approve its changes in the Console.

  - **Integrate Your App**
  - [Landing script and facts](/docs/platform/installation/attribution-script)
  - [Signup tracking](/docs/platform/installation/auth)
  - [Better Auth](/docs/platform/better-auth): Connect Better Auth signups to referral clicks with the RefRef plugin, with configuration only and no storage in your database.
  - [Auth.js](/docs/platform/installation/authjs)
  - [Supabase Auth](/docs/platform/installation/supabase)
  - [Clerk](/docs/platform/installation/clerk)
  - [Auth0](/docs/platform/installation/auth0)
  - [WorkOS AuthKit](/docs/platform/installation/workos)
  - [Referral Widget](/docs/platform/installation/widget)

  - **Integrations**
  - [Stripe](/docs/platform/stripe): Connect Stripe so invoices, payments, refunds, and subscriptions become RefRef facts, and deliver credit, promotion codes, and plan upgrades in Stripe.
  - [Dodo Payments](/docs/platform/dodo-payments): Connect Dodo Payments so payments, refunds, and subscriptions become RefRef facts, and deliver credit, discount codes, and plan upgrades in Dodo.
  - [Paddle](/docs/platform/paddle): Connect Paddle Billing so transactions, refunds, and subscriptions become RefRef facts, and apply discounts and free plan upgrades in Paddle.
  - [Polar](/docs/platform/polar): Connect Polar so orders, refunds, and subscriptions become RefRef facts, and apply discounts and free plan upgrades in Polar.
  - [RevenueCat](/docs/platform/revenuecat): Connect RevenueCat so in-app purchases, renewals, and refunds become RefRef facts, and give free premium access as a Reward with an entitlement.
  - [Shopify](/docs/platform/shopify): The RefRef app for Shopify - referral capture with consent, paid orders and refunds as facts, friend offers, store credit and discount code Rewards.
  - [WooCommerce](/docs/platform/woocommerce): Connect a WooCommerce store with the RefRef plugin - consent-based capture, paid orders and refunds as facts, friend offers, and referrer coupons.

  - **Guides**
  - [B2B SaaS](/solutions/b2b-saas)
- Automations: Zapier, Make, and Activepieces recipes
  - [Automations overview](/docs/automations): Connect RefRef to Zapier, Make, or Activepieces with a signed webhook and one API call.
  - [Zapier](/docs/automations/zapier): Verify a RefRef webhook in a Zap, grant the Reward, and confirm it with the RefRef API.
  - [Make](/docs/automations/make): Verify a RefRef webhook in a Make scenario with a filter, grant the Reward, and confirm it with the RefRef API.
  - [Activepieces](/docs/automations/activepieces): Verify a RefRef webhook in an Activepieces flow, grant the Reward, and confirm it with the RefRef API.
- API: RefRef API documentation
  - [API overview](/docs/api): Authenticate with a Workspace API key, choose the Sandbox or Live environment, read the error envelope, and find every API route.

  - **Reference**
  - [Approve Partner Application](/docs/api/approve-partner-application): Approve a partner application; the partner joins the Program. A write applies at once. Needs the partners:write key permission.
  - [Capture Handle](/docs/api/capture-handle): The landing script calls this route from the browser. It exchanges the `refref_handoff` of a
referral click for the handle of the browser, and keeps the handle in a first-party cookie. There
is no API key: the handoff is the credential, and it is valid for 15 minutes. `handle` is the
handle that the browser holds, if any; an unknown handle, or a handle of another Project, counts as
absent. A click goes to one handle, once. An open handle that the browser holds takes the click; a
handle that is already identified is replaced by a new handle. A retry of the same handoff without
a handle returns the handle that took the click. The response is not cached (`Cache-Control:
no-store`). A handoff that is not valid, or has expired, gets 400.
  - [Choose Reward Connection](/docs/api/choose-reward-connection): Choose the billing connection of a Reward that waits for a choice of provider. A write applies at once. Needs the rewards:fulfill key permission.
  - [Create Benefit Rule](/docs/api/create-benefit-rule)
  - [Create Custom Unit](/docs/api/create-custom-unit): Creates a custom unit. The key is what your product maps; it is fixed once a rule uses the unit.
  - [Create Program](/docs/api/create-program): Create a Program in one step: name, kind (referral for customers with the Widget, affiliate for partners with the join page, or loyalty), landing page URL, and optionally Widget settings and enrollment at sign-up (referral), partner applications (affiliate), and benefit rules with their first terms. A new Program is a draft: publish_program makes it live. A write applies at once. Needs the programs:write key permission.
  - [Create Referral Code](/docs/api/create-referral-code)
  - [Create Referral Link](/docs/api/create-referral-link)
  - [Create Webhook Endpoint](/docs/api/create-webhook-endpoint): Subscribes a URL to webhook events of the Project. An automation app subscribes with it and unsubscribes with DELETE. The endpoint keeps the current apiVersion. Its fulfillmentMode is on_delivery by default: a 2xx other than 202 to reward.earned records the Reward's fulfillment. Use explicit when the receiver confirms each grant through POST /v1/rewards/{rewardId}/fulfillment. The URL must use https and reach a public address.
  - [Decline Partner Application](/docs/api/decline-partner-application): Decline a partner application. A write applies at once. Needs the partners:write key permission.
  - [Delete Webhook Endpoint](/docs/api/delete-webhook-endpoint): Unsubscribes: deletes the endpoint, its deliveries, and their attempt log. The events stay in the feed.
  - [Diagnose Event](/docs/api/diagnose-event): Explain an Event: processing, attribution decision, and reward evaluations. Pending is not unattributed; an earned Reward does not prove payment delivery. Needs the referrals:read key permission.
  - [End Enrollment](/docs/api/end-enrollment)
  - [End Program](/docs/api/end-program): End a live or paused Program for good. Nothing new is tracked, and Events after the end earn nothing; earned Rewards are kept and still delivered. An ended Program cannot be reopened or changed. A write applies at once. Needs the programs:write key permission.
  - [Enroll Participant](/docs/api/enroll-participant)
  - [Recorded](/docs/api/event-recorded-webhook): RefRef recorded an Event with its attribution decision. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to event.recorded, and retries for about 72 hours until the endpoint answers 2xx.
  - [Fulfill Reward](/docs/api/fulfill-reward): Records that your product granted the Reward, or that you paid a cash Reward yourself. Only a Reward whose delivery method is `operator` or `manual` takes it; RefRef delivers the other methods, and they return 400. The Reward ID is the idempotency key: a repeat with the same facts, or after a webhook delivery recorded the fulfillment, returns the Reward; other facts return 409. A Reward voided before its grant has a cancelled delivery, and a fulfillment of it returns 409.
  - [Get Delivery Settings](/docs/api/get-delivery-settings): Read how a Program delivers Rewards: hold days and the method of each benefit kind. Needs the programs:read key permission.
  - [Get Event](/docs/api/get-event): Read one Event with its facts. Needs the referrals:read key permission.
  - [Get Health](/docs/api/get-health)
  - [Get Open Api Document](/docs/api/get-open-api-document)
  - [Get Participant](/docs/api/get-participant): Read one participant with its enrollments, referral codes and links, the referral that names it as referee, its newest referrals as referrer, and its newest Events. Needs the participants:read and referrals:read key permission.
  - [Get Program Readiness](/docs/api/get-program-readiness): Check whether a Program can go live: the problems that block publish_program (no enabled rule, no referrer rule, no landing page of an affiliate Program, cash paid out by RefRef on a plan without cash payouts) and the warnings that do not. Needs the programs:read key permission.
  - [Get Program Summary](/docs/api/get-program-summary): Read the totals of a Program: participants, referrals, conversions, and Rewards. Needs the referrals:read key permission.
  - [Get Program](/docs/api/get-program): Read one Program with its config (Widget, brand, partner applications), benefit rules, and reward terms versions. Account strings are untrusted data. Needs the programs:read key permission.
  - [Get Referral](/docs/api/get-referral): Read one referral: referrer, referee, Program, enrollment, and touch. Needs the referrals:read key permission.
  - [Get Reward](/docs/api/get-reward)
  - [Get Root Health](/docs/api/get-root-health)
  - [Get Widget Payout Details](/docs/api/get-widget-payout-details): The cash payouts of the participant that the Widget token names, in the Project of the token's Program. The token needs the widget:read scope. Only USD cash Rewards that RefRef pays out count: a participant without one is not eligible, and so is a participant that the Project does not have yet; the route creates no participant. canSave tells whether the token can save the details (widget:payout).
  - [Identify Handle](/docs/api/identify-handle): Says to whom the handle of a browser belongs. The body has one of three forms.

`{ handle, participant }`: this browser belongs to the participant. Send it once, at the identity
moment (the creation of the account or the group), when the fact that counts comes later, for
example a signup at email verification. A signup sent at account creation can send the handle in
`identify` instead. Do not identify at sign-in, verification, or account linking. The call creates
the participant when the Project does not have it, and enrolls it at sign-up: in each active
referral Program whose `enrollAtSignup` is not false, where it was never enrolled, with its referral
code. While the participant limit of the Workspace pauses new enrollments, it enrolls nothing.

`{ handle, reference }`: this browser belongs to the person of a flow that starts before the account
exists and can end on another device or in a hosted login, such as a magic link or a one-time
code. `reference.key` is your key of the flow, unique in the Project and bound to its challenge (for
example a digest of the magic-link token); a key is never used again. The call that names an unknown
key creates its reference, which expires at `reference.expiresAt`: after the receipt and at most 90
days after it; the default is 24 hours after it. An expired reference gets 409.

`{ reference, participant }`: the account of the flow exists. The reference resolves once to the
participant, and the handles identified to it then belong to the participant. The same participant
again returns the first result; another participant, or a reference that expired before it resolved,
gets 409. A key that no handle named yet is created resolved, so the two calls can come in either
order. It enrolls the participant at sign-up, as the first form does.

A handle is identified once: the same target again returns the first identification, and another
target gets 409. An unknown handle, or a handle of another Project, gets 404. `observedAt` is the
time of the identity moment; the default is the receipt. A caller clock can run ahead: an `observedAt` up
to 5 minutes after the receipt records the receipt, and a later one gets 400. The click window
of a handle ends at its identification, also when its reference resolves later. A fact uses only the
identifications and resolves that RefRef received at or before the fact; a fact never waits for one.
  - [Initialize Widget](/docs/api/initialize-widget): Initializes the Widget for the participant and the referral Program that the Widget token names. The request has no body. The token needs the widget:read scope. An affiliate or loyalty Program gets 400 INVALID_REQUEST. The response is not cached (Cache-Control: private, no-store).
  - [Intake Event](/docs/api/intake-event): Accepts one canonical Event of any type. A purchase sends `type: "purchase"` and its economic
facts in `purchase`; the server derives its key and time. A tenant-defined type, which starts with
`custom_`, sends its `type`, `sourceEventId`, and `occurredAt`. Names without the prefix are
reserved. A participant has one signup, so a `signup` can leave out `sourceEventId` and
`occurredAt`: its key is then derived from the participant, and its time is the receipt. A second
signup with another key gets 409. Every Event gets an attribution decision. The first Event of a
qualifying type of the Project (by default `signup` and `purchase`) with an eligible touch creates
the referral; a later Event of any type uses the referral, and the `referrer` and `referee` rules
of its type then evaluate it. The `subject` rules of the Programs in which the participant is
enrolled evaluate every Event. A type that is not built in, not a qualifying type of the Project,
and not named by a benefit rule of the Project is refused with 422. An Event carries no browser
data. Only a signup can carry `identify: { handle }`, which
identifies the handle of the browser where the account was created to the participant of the
signup, as POST /v1/identify does, in the same transaction. The handle comes from a browser cookie,
so any string of at most 4096 characters is accepted. A failed identification never fails the
Event: the response then has `identified: false`. A retry of a stored signup identifies no handle.
A new signup, with or without `identify`, enrolls its participant at sign-up as POST /v1/identify
does; a retry of a stored signup, or a signup dated before the Project's API source, enrolls no one.
Every Event can carry `refCode`: the one referral code that the referee entered. It is part of
the facts. The code counts when its owner was enrolled in the code's Program when the Event
occurred (or when RefRef received it, for an Event dated after its receipt), the Program is active,
and the owner is not the participant of the Event; otherwise RefRef ignores it. When the Event
creates the referral, a code that counts wins over every click. A purchase under a policy that
requires a new customer counts a code only on a first order, as it does a click.
  - [Intake Purchase Adjustment](/docs/api/intake-purchase-adjustment)
  - [Intake Subscription Fact](/docs/api/intake-subscription-fact)
  - [List Benefit Rules](/docs/api/list-benefit-rules)
  - [List Connections](/docs/api/list-connections): List the provider connections of a Project (billing sources and stores) with their state. No credentials are returned. Needs the integrations:read key permission.
  - [List Custom Units](/docs/api/list-custom-units): The custom units of the Project, oldest first. A rule's custom reward gives a quantity of one of them.
  - [List Events](/docs/api/list-events): List the Events of a Project, newest first, 50 per page, with their processing state. Use diagnose_event for one Event. Needs the referrals:read key permission.
  - [List Participants](/docs/api/list-participants): List the participants of a Project, newest first, 50 per page (offset as a decimal string). kind filters individual or group. Needs the participants:read key permission.
  - [List Partners](/docs/api/list-partners): List the partners of a Project with their invitations and applications. Needs the partners:read key permission.
  - [List Program Rules](/docs/api/list-program-rules): List the benefit rules of a Program. Needs the programs:read key permission.
  - [List Program Templates](/docs/api/list-program-templates): List the Program templates (starting points for common business models) with their suggested rules.
  - [List Programs](/docs/api/list-programs): List the Programs of a Project, oldest first, with their enrollment and referral counts. Needs the programs:read key permission.
  - [List Projects](/docs/api/list-projects): List the Projects that this credential reaches in the Workspace, with environment (sandbox or live) and qualifying event types. Select a Project explicitly before other operations.
  - [List Purchases](/docs/api/list-purchases): List the purchases of a Project, newest first, 100 per page (offset). Needs the referrals:read key permission.
  - [List Referee Offers](/docs/api/list-referee-offers): List the referee offer versions of a referral Program, newest first. Needs the programs:read key permission.
  - [List Referrals](/docs/api/list-referrals): List the referrals of a Project, newest first, 50 per page. Needs the referrals:read key permission.
  - [List Referrers](/docs/api/list-referrers): List the participants with an enrollment (open or ended), newest first, 50 per page. Needs the participants:read key permission.
  - [List Reward Adjustments](/docs/api/list-reward-adjustments): List the reward adjustments (refunds, disputes, restorations), newest first, 100 per page (offset). Needs the referrals:read key permission.
  - [List Reward Evaluations](/docs/api/list-reward-evaluations): List the reward evaluations, newest first, 100 per page (offset): each rule decision of each Event. Needs the referrals:read key permission.
  - [List Reward Terms](/docs/api/list-reward-terms): List the reward terms versions of a benefit rule, newest first. Needs the programs:read key permission.
  - [List Rewards](/docs/api/list-rewards): A page of Rewards, newest first, with their fulfillment status. Your product grants only the Rewards of the delivery methods operator and manual; RefRef delivers the others. To grant the Rewards that a webhook did not reach, read deliveryMethod=operator (and manual) with fulfillmentStatus=pending.
  - [List Webhook Deliveries](/docs/api/list-webhook-deliveries): List webhook deliveries newest first, 50 per page; filter by endpointId or state. Needs the webhooks:read key permission.
  - [List Webhook Endpoints](/docs/api/list-webhook-endpoints): The webhook endpoints of the Project, oldest first, without their secrets.
  - [List Webhook Events](/docs/api/list-webhook-events): Webhook events in commit order after the cursor. A late commit never appears behind a cursor, so a product that missed webhooks catches up from its last next. The webhooks section lists each event type and its data.
  - [List Widget Referrals](/docs/api/list-widget-referrals): The referrals where the participant that the Widget token names is the referrer, in the referral Program of the token, newest first. The token needs the widget:read scope. A participant that the Project does not have gets an empty list; the route creates no participant. An affiliate or loyalty Program gets 404 NOT_FOUND; a cursor that is not valid gets 400 INVALID_REQUEST. The response is not cached (Cache-Control: private, no-store).
  - [List Widget Rewards](/docs/api/list-widget-rewards): The Rewards that credit the participant that the Widget token names, in the referral Program of the token, newest first, each with its Widget status. The token needs the widget:read scope. The first page (no cursor) has the summary. A participant that the Project does not have gets an empty list; the route creates no participant. An affiliate or loyalty Program gets 404 NOT_FOUND; a cursor that is not valid gets 400 INVALID_REQUEST. The response is not cached (Cache-Control: private, no-store).
  - [Created](/docs/api/participant-created-webhook): RefRef created a participant: a trusted call or a Widget token named one that the Project did not have, or a partner joined the Project. A partner has no externalId. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to participant.created, and retries for about 72 hours until the endpoint answers 2xx.
  - [Pause Program](/docs/api/pause-program): Pause a live Program: no new referrals or enrollments, and links open the landing page without tracking. Earlier referrals keep earning Rewards. resume_program undoes it. A write applies at once. Needs the programs:write key permission.
  - [Failed](/docs/api/payout-failed-webhook): A payout failed before payment. Its Rewards wait for the next payout. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to payout.failed, and retries for about 72 hours until the endpoint answers 2xx.
  - [Paid](/docs/api/payout-paid-webhook): A payout paid cash Rewards of the Project. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to payout.paid, and retries for about 72 hours until the endpoint answers 2xx.
  - [Returned](/docs/api/payout-returned-webhook): The provider returned a payout, before or after its payment. The next payout pays its Rewards again. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to payout.returned, and retries for about 72 hours until the endpoint answers 2xx.
  - [Publish Attribution Policy](/docs/api/publish-attribution-policy)
  - [Publish Program](/docs/api/publish-program): Make a draft Program live, so it takes referrals, enrollments, and Rewards. Refused with the problems of get_program_readiness when it is not ready. A write applies at once. Needs the programs:write key permission.
  - [Publish Referee Offer](/docs/api/publish-referee-offer): Publish a new referee offer version: what a referred person gets, as shown in the Widget and join page. A write applies at once. Needs the programs:write key permission.
  - [Publish Reward Terms](/docs/api/publish-reward-terms)
  - [Record Referral](/docs/api/record-referral): Record a referral that you already know, for example from a support ticket or a sales call: the referee (by kind and your external ID; RefRef creates it when it does not know it), the referrer (by kind and external ID, or by its referral code, the only way to name a partner), and the Program. The referrer must be enrolled in the Program now. A referee that already has a referral is a conflict, and so is a referee with a purchase when the attribution policy accepts only new customers. The referral has no binding fact: Events that RefRef receives after it use it. A write applies at once. Needs the referrals:write key permission.
  - [Created](/docs/api/referral-created-webhook): RefRef bound a referral: attribution found a referrer for the referee of an Event or a Subscription, or you recorded the referral. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to referral.created, and retries for about 72 hours until the endpoint answers 2xx.
  - [Voided](/docs/api/referral-voided-webhook): An operator voided a referral. Its Rewards are voided, and later Events of the referee get no referral. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to referral.voided, and retries for about 72 hours until the endpoint answers 2xx.
  - [Rekey Participant](/docs/api/rekey-participant): Renames the participant that the body names by kind and external ID to newExternalId, for example when your user IDs change. The kind stays. The old ID is retired: it keeps naming the same participant in every call, and it never names another participant of the Project and kind. Name the participant by its current external ID. A retry that names the old ID again returns the participant and changes nothing. An unknown or deleted participant returns 404; the call creates no participant. A new ID that another participant has, or that a rename retired, returns 409, and so does a name that is no longer the current ID. A fact keeps the participant reference that it was sent with: a retry of an earlier fact must name the participant as the first request did.
  - [Rename Benefit Rule](/docs/api/rename-benefit-rule): Change the name of a benefit rule. The rule and its terms do not change. A write applies at once. Needs the programs:write key permission.
  - [Resume Program](/docs/api/resume-program): Make a paused Program live again. A write applies at once. Needs the programs:write key permission.
  - [Retry Reward Delivery](/docs/api/retry-reward-delivery): Make a failed RefRef delivery of a Reward due again. A write applies at once. Needs the rewards:fulfill key permission.
  - [Revoke Partner Invitation](/docs/api/revoke-partner-invitation): Revoke an open partner invitation. A write applies at once. Needs the partners:write key permission.
  - [Revoke Reward](/docs/api/revoke-reward): Records that your product took back a voided Reward that it had granted. Only a Reward whose delivery method is `operator` or `manual` and whose status is `revocation_pending` takes it; a cash Reward is never revoked. A repeat with the same facts returns the Reward; other facts return 409.
  - [Earned](/docs/api/reward-earned-webhook): A participant earned a Reward. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to reward.earned, and retries for about 72 hours until the endpoint answers 2xx.
  - [Fulfilled](/docs/api/reward-fulfilled-webhook): A Reward was fulfilled: your product, the Console, a webhook answer, or RefRef delivered it. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to reward.fulfilled, and retries for about 72 hours until the endpoint answers 2xx.
  - [Revoked](/docs/api/reward-revoked-webhook): Your product took back a voided Reward that it granted. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to reward.revoked, and retries for about 72 hours until the endpoint answers 2xx.
  - [Voided](/docs/api/reward-voided-webhook): An operator voided a Reward. RefRef POSTs the event to each enabled endpoint of the Project that subscribes to reward.voided, and retries for about 72 hours until the endpoint answers 2xx.
  - [Save Widget Payout Details](/docs/api/save-widget-payout-details): Records the country and the PayPal address of the participant that the Widget token names, with its acceptance of the current payout terms (acceptTerms). The token needs the widget:payout scope. Without paypalEmail the save keeps the current PayPal address, for example to accept new terms; the first save without it gets 400 VALIDATION_ERROR. Only an eligible participant gives payout details, and only when a Program of its cash Rewards offers PayPal; another participant gets 400 INVALID_REQUEST, and so does a participant whose payout details are blocked. In a Live Project, an address in a reserved test domain (.test, .example, .invalid, .localhost, example.com, example.net, or example.org) gets 400 INVALID_REQUEST. The same details again change nothing; a new address replaces the default method.
  - [Set Qualifying Event Types](/docs/api/set-qualifying-event-types): Set the Event types that create a referral in the Project (default signup and purchase). A write applies at once. Needs the programs:write key permission.
  - [Submit Paid History](/docs/api/submit-paid-history)
  - [Update Custom Unit](/docs/api/update-custom-unit): Renames or archives a custom unit. A new name shows everywhere at once; an archived unit takes no new rules.
  - [Update Delivery Settings](/docs/api/update-delivery-settings): Change how a Program delivers Rewards: hold days and the method of each benefit kind. Fields that you leave out keep their values. A write applies at once. Needs the programs:write key permission.
  - [Update Program](/docs/api/update-program): Change the name or some settings of a Program: brandConfig, widgetConfig, partnerApplicationsOpen, enrollAtSignup. Settings that you leave out keep their current values. A write applies at once. Needs the programs:write key permission.
  - [Upsert Participant](/docs/api/upsert-participant): Registers the participant that the body names by kind and external ID: the call resolves it or creates it, and writes the name, email, and billing ID that the body gives. An ID that POST /v1/participants/rekey retired names the renamed participant, and the response gives its current external ID. A field that the body leaves out stays as it is; null clears a name or an email. The billing ID is the participant's customer ID in the Project's billing provider, which delivers account credit and discount Rewards; it is set once. A billing ID that differs from the participant's, or that another participant of the Project has, returns 409. A new billing ID makes the Rewards that wait for it due at once.
  - [Void Referral](/docs/api/void-referral): Void a referral with a reason code and a reason, for example when the referee is a fake or duplicate account. A void is final: the referral stays in the history, each of its Rewards is voided, later Events of the referee get no referral, and no new referral forms for the referee. A write applies at once. Needs the referrals:void key permission.
  - [Void Reward](/docs/api/void-reward): Void an earned Reward with a reason code and a reason. A void is final; the Reward stays in the history. A write applies at once. Needs the rewards:void key permission.