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:
| If you want to… | Use |
|---|---|
| Drop chrome (cart, auth, search, …) into an existing landing | Widgets — <script> tag + <div data-cobuntu-*>, or import { Cart } from "@cobuntu/widgets" |
| Sync data, automate, or build an integration | REST API + Webhooks — scoped API keys, OpenAPI spec, HMAC-signed delivery |
| Ship a full custom app on top of Cobuntu | Server SDK — typed Node client, CLI tunnel, landing template |
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.
Two consumption patterns
Before you pick a layer, read Two consumption patterns. There are 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. Live: Orbis, DDDIMO. - 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. Live: Bela Escala.
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.