> ## Documentation Index
> Fetch the complete documentation index at: https://partner-help.letsdothis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Membership API

> Find memberships, read benefits and billing status, update member details, and open a billing portal from your server.

Use the membership endpoints to integrate membership management into your application.
A **policy** holds the purchase and billing relationship. A **membership** is one
person's place on that policy. A policy whose plan covers more than one person
can have several memberships: a primary member plus secondary members. Secondary
members can be added after purchase, so a policy's member list can grow.

> [!NOTE]
>
> The membership API is in beta: its request and response contract can still
> change while it's being developed.

Requests, authentication, paging and errors work as described in the
[API overview](/api-reference/overview.md). Membership operations need an
unrestricted organizer key; [scoped keys](/api-reference/scoped-keys.md) receive
`403`. Each endpoint's reference page describes its fields.

## Member access

Your key can read every membership in your organization and open a billing
portal for any of its members, so your app must check which member is signed in
and only pass their own policy and membership IDs. Don't trust an ID sent by
your client, and don't treat knowing an email address as proof of identity.
Your app also enforces the member's primary or secondary role.

## Typical flow

1. [Find the member's memberships by email](/api-reference/endpoints/membership/find-memberships-by-email.md) after they sign in. An email can
   return several memberships and policies, so don't assume the first one is
   the only one.
2. Read the [policy dashboard](/api-reference/endpoints/membership/get-a-membership-dashboard.md) for its status, renewal and price.
3. Read the membership's [entries](/api-reference/endpoints/membership/list-the-races-linked-to-a-membership.md) and
   [member details](/api-reference/endpoints/membership/read-member-details.md) as your app needs them.
4. Open a [billing portal session](/api-reference/endpoints/membership/create-a-membership-billing-portal-session.md) when the member wants to change their payment
   method, and redirect them to it straight away.

## Access and status

Use `entitled` to decide whether the member has access. `status` explains why,
and `paymentFailed` warns that a renewal payment has failed before access is
lost, so it can be true while `entitled` is still true. Treat unknown future
values conservatively.

## Prices

Amounts are in minor currency units: `12000` in `DKK` means DKK 120.00. An
offering's current price is what a new member would pay. An existing member
pays the price on their policy dashboard, which can be a revision that is no
longer on sale. The organizer can move existing policies to a newer revision
when the price changes, so an existing member's price can rise.

## Keeping data fresh

Every read returns current data, so read when your app needs it: on sign-in,
when a membership view opens, and when the member returns from the billing
portal. Timed background polling isn't needed. There are no membership
webhooks.

## Data that is never returned

Membership responses never include Stripe account, customer, subscription,
product or price IDs, payment method IDs, internal subscription configuration
IDs, client secrets or full card numbers.
The optional card details contain only the last four digits. The billing portal
URL is the one short-lived credential returned; don't log, store or share it.
Reservation codes and claim links aren't returned either: a member claims a
reserved place from the email sent when it's reserved.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.