Skip to main content
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.
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. Membership operations need an unrestricted organizer key; scoped keys 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 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 for its status, renewal and price.
  3. Read the membership’s entries and member details as your app needs them.
  4. Open a billing portal session 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.