Skip to content
CursareDocs
Sign in

Start here

  • Overview
  • Getting started
  • Platform concepts

Create

  • Content
  • Editor and blocks
  • Block reference

Publish & access

  • Publishing and access
  • Custom domain & white-label

Learners

  • Learner experience
  • Learners and enrollments
  • Progress and certificates

Teams & cohort

  • Teams
  • Cohorts

Sales

  • Offers & checkout
  • Payments & payouts
  • Affiliates
  • Insights and reports

Admin

  • Organization & security
  • Plans, trial & billing
  • Appearance
  • Members & roles
  • Audit log

Developer

  • Integrations
  • API keys & webhooks
  • MCP server
  • API reference
Explore the API
Publish & access

Custom domain and white-label

Every organization gets a Cursare address the day it is created, and can graduate to its own domain. This page explains the two addresses your brand lives at, how to connect your own, and the one invisible seam — login — that keeps the white-label experience seamless.

The org subdomain and public storefront

The moment an organization exists it is reachable at its own subdomain: {slug}.cursare.com, where slug is the organization's slug. All host-based routing happens at the edge (in proxy.ts): a request to acme.cursare.com is rewritten into that organization's /[org]/… routes, so the creator never has to configure anything to go live.

A handful of subdomains are reserved and can never be taken as an org slug — www, app, api, docs, about, privacy, terms, cdn, assets, and mail. mcp is a first-class host too — it routes to the MCP endpoint — so it is not usable as a storefront subdomain either. Everything else under cursare.com that resolves to a single label is treated as an org slug.

The organization's published catalog powers its public storefront:

SurfaceRouteWhat it shows
Storefront/[org] (served at {slug}.cursare.com)The organization's branding — logo, name, bio — over its published, listed courses as cards.

The storefront lists only content that is published and listed for that organization, drawn from listPublishedForOrg, with review stars per course. Cursare does not aggregate those catalogs into a platform-wide discovery surface; each school owns its public distribution and learner relationship.

Slug drives the address

The subdomain follows the organization slug. Renaming the slug moves the storefront to the new subdomain, so treat it like a public URL — pick it deliberately and avoid churning it once learners have the link.

Connecting your own domain

An organization can serve its storefront and courses from a domain it owns — courses.yourbrand.com — under Settings → Domains. You enter the domain, add two DNS records at your registrar, and Cursare takes care of the rest.

The DNS records

Saving a domain produces exactly two records to add at your DNS provider, both with a TTL of 3600 (kept low so the change propagates fast enough for automatic verification):

TypeNameValuePurpose
CNAMEyour domain (e.g. courses.yourbrand.com)cname.vercel-dns.comPoints the domain at Cursare's hosting so requests reach the app.
TXT_cursare-verify.<your-domain>a unique verification tokenProves you own the domain before it goes live.

Each value has a copy button in the Domains card, so you can paste it straight into your registrar.

Automatic verification and TLS

Once the domain is saved but not yet verified, the Domains card polls your DNS automatically every few seconds — you never have to click anything. When the TXT record at _cursare-verify.<domain> matches the expected token, Cursare:

  1. Registers the domain on Vercel, which provisions and renews the TLS certificate and routes the host to the app.
  2. Marks the domain verified, and the card flips to a live confirmation linking to https://<your-domain>.

A manual Verify button is available too, for when you would rather not wait for the next poll. Until the records resolve, the card simply keeps checking and shows the pending DNS instructions.

DNS takes a few minutes

New records can take a few minutes to propagate before the TXT lookup succeeds. If verification has not flipped yet, the record is usually still propagating — the poller will catch it. Double-check the record name and value if it stays pending for long.

Behind the scenes, the edge resolves an incoming custom-domain request to its organization and serves that org's public routes — the same /[org] storefront and course pages, just on your host.

One identity, a session for each school

Learners browse, buy, enroll, and study without leaving the school's host — both on {slug}.cursare.com and on a verified custom domain. Cursare still owns the identity: sign-in briefly opens on cursare.com, shows which school will receive the learner's name and email, and asks for explicit consent before returning.

The school receives a separate, opaque session bound to that exact host and organization. It cannot be reused on another school, the dashboard, the REST API, or MCP. It expires after 7 idle days or 30 total days, whichever comes first. Signing out on the school clears that local session without signing the learner out of every other Cursare experience.

School scripts share the learner boundary

Analytics, affiliate, and tag-manager scripts configured by the organization run on its storefront and can observe what the learner sees on that school. They never receive the apex Cursare session, password, OAuth code, API key, or MCP credential. Connect only scripts you trust and describe them in your privacy notice.

Checkout returns to the same school host after the payment provider confirms the transaction. Enrollment, content access, progress, discussions, cohorts, polls, and certificates remain scoped to that school's organization on every server operation.

Custom-domain ownership monitoring

Cursare keeps checking the verified TXT and routing records. A temporary DNS lookup failure does not interrupt learners. A confirmed ownership or routing change disables the domain's login client, revokes its local sessions, and marks the domain unverified until its records are fixed and verified again.

What stays on Cursare

The public, learner-facing experience is what white-labels. The admin dashboard does not: producers and staff always manage their operation from Cursare itself.

  • The dashboard (/dashboard), account, billing, and shared identity pages stay on cursare.com behind the apex host-only session.
  • A school host serves only learner authentication endpoints. /api/v1, MCP, dashboard, account, billing, and Better Auth endpoints remain apex-only and require their normal Bearer or apex-session credentials.

In short: learners stay on the school's host; identity and administration stay controlled by Cursare.

Keep exploring

Publishing and accessPublish content and decide who gets in.AppearanceLogo, colors, and public branding.Organization and securitySlug, settings, and account safety.Learner experienceHow reading, progress, and release feel.
PreviousPublishing and accessNextLearner experience

Your privacy choices

Necessary cookies keep Cursare working. Analytics and marketing technologies are optional and stay off until you choose them. Privacy Policy.

Sign-in, security and core platform functions.

Audience measurement such as Google Analytics.

Tag Manager and campaign attribution.