Community config

Every Cobuntu community has a handful of access-control switches that decide who can see the community at all, who can apply, and which routes are available to which viewers. Most are flipped from cobuntu-admin → Settings. This page is the reference for what each setting does — and how to read them via the API if you're building a custom dashboard or integration.

Mental model. Three independent axes:

1. Visibility — can anonymous people READ the community's Cobuntu pages (feed, events, marketplace, members, …)?
2. Accessibility — how can NEW people get IN?
3. Page settings — per-page overrides on top of #1, plus per-page enable/disable.

Everything else (members-only feed, founder-only marketplace, public flagship event) is built from these three primitives plus per-entity visibility on individual events / posts. See Integration modes for the full picture of how these axes compose into the three named modes.

1. Community visibility

The org-wide default for whether anonymous visitors can read your Cobuntu pages. Two possible values — flip via cobuntu-admin → Settings.

The two are the only values in the CommunityVisibility enum. Most customers today run PUBLIC with selective per-page lockdowns (see Page settings below); MEMBERS_ONLY is an explicit choice when the membership itself is the value prop.

Read it via:

GET /api/communities/<communityTag>

{ "visibility": "PUBLIC" | "MEMBERS_ONLY", ... }

2. Accessibility — how new members get in

The "Apply" surface (/apply) reads this value to decide what to render. The community-app's onboarding gate also reads it to decide whether to send a stranger to the application form or to the tier-picker.

{ "accessibility": "OPEN" | "APPLICATION" | "INVITE_ONLY", ... }

3. Per-page settings

The community-app ships eight feature surfaces — Feed, Events, Marketplace, Members, Atlas, Blog, Chat (DMs), Home. Each can be enabled / disabled and gated independently. When a page is disabled it's hidden from the Cobuntu nav, removed from embed snippets, and the reverse proxy yields the route to your landing host so you can author your own page at that path. See Integration modes → Flavour A for the full behavior.

The pageSettings field on the community is an array, one entry per page key:

{
  "pageSettings": [
    { "pageKey": "CHAT",        "enabled": true,  "visibility": null },
    { "pageKey": "MEMBERS",     "enabled": true,  "visibility": "MEMBERS_ONLY" },
    { "pageKey": "FEED",        "enabled": true,  "visibility": "MEMBERS_ONLY" },
    { "pageKey": "BLOG",        "enabled": false, "visibility": null },
    { "pageKey": "EVENTS",      "enabled": true,  "visibility": null },
    { "pageKey": "MARKETPLACE", "enabled": true,  "visibility": null },
    { "pageKey": "ATLAS",       "enabled": true,  "visibility": "MEMBERS_ONLY" }
  ]
}

enabled

• true — the page renders, the nav item shows (subject to visibleWhen), and the data API for the page returns.
• false — the page is hidden from nav, the route returns the community's not-found surface, the data API still returns for admin tooling but isn't exposed in member-facing UI.

visibility

Page keys reference

The HOME key exists in the modules object but isn't usually flipped — disabling Home would leave the apex with nothing to serve.

Serving a page from your own app (externalPages)

Disabling a page (enabled: false) hands its route to your landing and removes it from the Cobuntu nav — good when you author your own /blog and don't want to advertise Cobuntu's. Sometimes you want the opposite: keep the page in the nav (members still see "Marketplace") while serving the page itself from your own app.

That's storefrontConfig.externalPages — a list of page keys you serve yourself:

{
  "storefrontConfig": {
    "externalPages": ["MARKETPLACE"]
  }
}

For each listed key, on your apex Cobuntu:

• keeps the nav item — the page stays enabled and its link still shows in the header, mobile drawer, and branded footer, and
• serves the route — and its sub-routes — from your landing instead of Cobuntu's built-in page. With ["MARKETPLACE"], both /marketplace and /marketplace/<sku> render from your app.

Toggle it per page in cobuntu-admin → Settings → Visibility ("Serve this page from my own site").

Your site must actually serve the route. If your landing returns a real 404 for the path, Cobuntu falls back to its built-in page. But single-page apps that answer 200 to every path (and render a client-side "not found") can't be detected — visitors would see your app's not-found page. Make sure the route exists before enabling it.

4. Entity-level visibility (the fourth layer)

pageSettings gates the route. A separate per-entity visibility-overrides layer gates individual chapters, events, products, members within an enabled route. So you can have:

• The Marketplace page enabled and PUBLIC (anyone can browse).
• Inside it, one specific product set to MEMBERS_ONLY (only members see the listing in the grid + can hit the detail page).

The override surface is configured in the entity's own admin UI (event manage page, product manage page, chapter settings).

5. The full evaluation order

When a viewer hits yourdomain.com/events:

1. Page enabled check. If pageSettings[EVENTS].enabled === false → not-found.
2. Page visibility check. Resolve effective visibility: pageSettings[EVENTS].visibility ?? community.visibility. If MEMBERS_ONLY and viewer isn't ACCEPTED → gate page (reason: page_members_only or community_private).
3. Page renders. The route handler runs; individual entities within it (event cards, product cards) are filtered through their own per-entity visibility column.
4. Per-entity check when viewer clicks into a detail page. /events/<slug> bypasses step 2 entirely and evaluates the event's own viewability column directly — this is what lets a fully-private community publish a single public event.

All four layers fail closed — when in doubt, gate.

See Integration modes → Layer 2 for the entity-level shape, and Integration modes → The rule that runs them all for the resolver-rule diagram that step 2 implements.

6. Reading + writing via API

Read

GET /api/communities/<communityTag>

Returns the full community object including visibility, accessibility, pageSettings, storefrontConfig, themeConfig.

GET /api/communities/by-domain/<hostname>

Same shape, resolved by custom apex. Used by widgets to auto-theme; also useful for integrations that only have the hostname.

Write

Live changes are made in cobuntu-admin → Settings. We don't expose a public PATCH on /api/communities/<tag> yet — the admin app is the source of truth and knows how to validate combinations (e.g. disabling the only enabled page in a mode that needs at least one public page emits a warning). When we open a public write endpoint for these fields it'll be /api/v1/... under the same scope-gated auth as the rest of the public write API.

See also

• Whitelabel shell — the visual chrome that wraps every page, also driven by community config.
• Two consumption patterns — what changes for Headless API vs. Hosted apex.
• REST API → authentication — how the scope-gated public write API will eventually expose these fields under v1.