Build on Cobuntu

Cobuntu is the platform community founders run their community on — membership, payments, events, marketplace, atlas, chat, all behind white-label landing pages and customer-owned domains. The Cobuntu SDK is everything a developer needs to extend, integrate with, or ship on top of that platform.

There are three ways to consume Cobuntu:

Most customers start with Widgets (no build step required — paste a script tag in Squarespace, Webflow, Lovable, plain HTML) and graduate to the REST API + webhooks when they need automation, then to the Server SDK when their landing outgrows the template.

Quick start (5 minutes)

If you already have a community on Cobuntu, the fastest path to working code:

<!-- 1. In your landing's footer code-injection slot -->
<script src="https://app.cobuntu.com/widgets/v1/cart.js" async></script>
<script src="https://app.cobuntu.com/widgets/v1/auth.js" async></script>
 
<!-- 2. Anywhere in your header -->
<div data-cobuntu-cart></div>
<div data-cobuntu-auth data-variant="button"></div>

Open the page, click the auth button, log in — you should see your community's chrome wired up. From there, widget docs covers every data-attribute + CSS variable contract for theming.

Pick your integration mode

Before you pick a layer, you need to know what shape your community takes. There are three:

• Portal — community is MEMBERS_ONLY, no pages opened up. Like a Slack workspace. Zero SEO. Best for paid masterminds.
• Storefront — community is PUBLIC, no pages gated. Max SEO + GEO discoverability. Best for content-led communities.
• Hybrid — any per-page override flips you here. Two flavours: Blocklist (PUBLIC default, gate the inner ring) and Allowlist (MEMBERS_ONLY default, publish a few pages outward).

Full breakdown at Integration modes.

Pick your consumption pattern

Two ways to deploy on Cobuntu:

• Headless API — your apex DNS points at your own infra. You build everything (landing, routes, dashboards) and call api.cobuntu.com/api/v1/* from your server with an API key. Cobuntu is purely a data backend. Best when you have engineers + want full control over UI/routing/SSR.
• Hosted apex — your apex DNS points at Cobuntu's Vercel. Cobuntu serves your landing (reverse-proxied from wherever you host it: Lovable, Squarespace, your own Next.js, anywhere) AND Cobuntu's product surfaces (/events, /marketplace, /checkout, ...) on the same origin. Auth, cart, checkout "just work" across both. Best when you want a no-code or low-code landing + Cobuntu's UI for everything else.

Full breakdown at Consumption patterns. The choice is about where your apex DNS points, not about which framework you use. Lovable, Next.js, Webflow, plain HTML — any of them work in either pattern.

Configuring the community

Two reference pages cover the configuration surface that drives every white-label community:

• Whitelabel shell — how the header, nav, footer, and brand tokens stay in lockstep between your landing and Cobuntu's product surfaces. One edit in cobuntu-admin → Customize, both surfaces repaint on next page-load.
• Community config — visibility (PUBLIC / MEMBERS_ONLY / PRIVATE), accessibility (OPEN / APPLICATION / INVITE_ONLY), and the per-page enable / gate toggles for Feed, Events, Marketplace, Members, Atlas, Blog, Chat. Plus the per-entity overrides layer on top.