X-CommunityId

Memberfy is organized by community, and so is the API: almost every call needs the X-CommunityId header with the community's id.

X-CommunityId: 3562c7a0-0000-0000-0000-000000000000

#What it decides

1. Where the operation happens: which community the space is created in, the product is listed in, the payout is requested from.
2. Which role you have: permission is checked against your profile in that community. The same account can be the owner of one community and a member of another; the header picks which one applies.

#The header rules, not the path

No route carries the community in the path. Products, coupons, plans, fees, statement, payouts, reports, business information, payout settings and subscription management live at paths without the community id (/api/products, /api/coupons, /api/manage/subscriptions…), and the community comes only from X-CommunityId. Without the header, these routes answer 400.

This isn't a detail: with a single source for the community, there's no way to act in another one by changing an id in the URL.

The exception is the SuperAdmin acting on another community, at /api/admin/communities/{communityId}/fee-overrides/...: there the id in the path is the target community, not the caller's context. The community's own routes, PUT and DELETE /api/communities/{id}, GET /api/communities/{id}/members and PATCH /api/communities/{id}/settings, carry the id because the community is the resource itself; the header is still required on them.

Changed on October 6, 2026. The old /api/communities/{communityId}/... paths (products, coupons, plans, fees, statement, payouts, reports, subscriptions, purchases, checkout, business information, payout settings) were removed, with no transition period, and answer 404. Switch to the same path without the prefix, under /api/...; team subscription management moved to /api/manage/subscriptions, and e-mail stats to /api/emails/stats. The SDK method names didn't change. See The paths that changed.

Some older routes also ask for communityId in the body (creating a course, inviting members). Send the same id as in the header.

#The paths that changed

On October 6, 2026, each path below lost the /api/communities/{communityId} prefix. HTTP methods, parameters, bodies, responses and required roles stay the same.

The SDK method names and the reference pages stay the same, because each route kept its operationId: /api/products is still api.products.postCommunitiesByCommunityIdProducts. Only the nine nested checkout operations are gone; use the ones under /api/checkout/*.

#Where to find the community id

curl -s https://api.memberfy.net/api/communities/my \
  -H "Authorization: Bearer $TOKEN"

#The errors you get when you forget it

A 400 from a missing header is the number one cause of API errors.

#Example

curl -s https://api.memberfy.net/api/products \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-CommunityId: $COMMUNITY_ID"

#In the SDK

Call api.setCommunity('<uuid>') once, and the SDK sends the header on every call. To switch communities, call setCommunity again. See JavaScript SDK.

#Frequently asked questions

Can one integration serve two communities? Yes, with an account that has a role in both: change the header on each call.

Do the authentication routes need the header? No: sign-in, sign-up and GET /api/auth/me work without it.

#Related

• Authentication
• Community
• Responses and errors