Docs

Multiple Websites

Run several websites from one Workspace, each with its own CMS collections, API v2 addresses, and SDK client.

cmswebsitescollectionsapisdk

Multiple Websites

One Workspace can run several websites, for example one per client. Each website has its own CMS collections, so two websites can both have a blog collection without prefixing slugs with a client name.

Websites and collections

  • Every CMS collection belongs to exactly one website. Nested collections always belong to the same website as their parent.
  • Collection slugs are unique per website, not per Workspace. blog can exist once in every website.
  • A website can also have a builder site, a connected SDK site, and analytics. A website without any of them is a valid content-only website that external code reads through API keys.
  • Builder sites and in-page editing on a connected site only see the collections of their own website.
  • A relation field can target a collection in another website. API keys and connected sites must also be allowed to read that target collection to include its records.

Find a website's collections

  • Websites lists the websites of the Workspace. Open a website and select its Collections tab, then open a collection to work with its records.
  • The breadcrumb shows Websites › website › Collections › collection. Select Websites to return to all websites.
  • A new collection is created in the website you are viewing.
  • When the Workspace has only one website, the sidebar entry opens that website directly.

Website slug

  • Every website has a slug that is generated from its name and is unique within the Workspace. API v2 URLs and the SDK use it to name the website.
  • To see or change it, open Websites, select the website, and go to Settings › General.
  • Changing the slug changes every API v2 URL of that website. Connected sites must regenerate their SDK client with the new slug and update any URLs they build themselves.

Public API v2

API v2 names the website in every CMS address:

GET /api/v2/cms/<website-slug>/<collection>
GET /api/v2/cms/<website-slug>/<collection>/<record-slug>
  • /api/v2/cms/acme/blog and /api/v2/cms/mueller/blog are two different collections.
  • Native resources such as events or jobs keep their Workspace-wide address, for example /api/v2/events.
  • /api/v2/schema returns the OpenAPI document for the API key, and the resource index at /api/v2 lists each CMS collection with its website.

SDK 3.0

@einblick/sdk 3.0 talks to API v2. A client is bound to one website, so collection slugs in your code stay plain. Generate the typed client for one website with einblick-sdk generate --website <slug>:

npx @einblick/sdk generate --website acme --output app/lib/einblick.generated.ts
  • The generator picks the website by itself when the API key reads collections of only one website. When the key reads several, --website <slug> is required and the other websites' collections are left out of the generated file.
  • The generated file exports EINBLICK_WEBSITE, the slug the client is bound to. Pass it to createEinblickCmsTags({ website: EINBLICK_WEBSITE }) when you tag cached reads.
  • A hand-written client names the website once:
import { createEinblickClient } from '@einblick/sdk'
 
const einblick = createEinblickClient({ website: 'acme' })
const posts = await einblick.request('blog', { limit: 10 })
  • A client without a website can still read native resources, but a CMS read throws EinblickWebsiteRequiredError before any request is sent.
  • Dashboards, aggregators, and sync jobs that really span websites use the Workspace client and name the website per call. Client sites should keep using the bound client.
import { createEinblickWorkspaceClient } from '@einblick/sdk'
 
const workspace = createEinblickWorkspaceClient()
const acmePosts = await workspace.request({ website: 'acme', resource: 'blog' })
const mueller = workspace.website('mueller')

API keys across websites

  • One API key may read collections of several websites. In System Settings → API, the key sheet shows a website badge next to each collection when the Workspace has several websites.
  • The sheet warns when a key reads the same collection slug from several websites.
  • API v1 addresses collections by slug only (/api/v1/cms/<slug>). When the key reads that slug from several websites, a v1 request fails with 400 and names the matching websites instead of picking one. Move these callers to API v2 or SDK 3.0, or give each website its own key.

Move a collection to another website

  • Use Move to website… in the collection settings to move a collection into another website. Its nested collections move with it.
  • The target website must not already have a collection with the same slug.
  • After the move, the collection's API v2 URL uses the new website's slug. Regenerate the SDK client of every site that reads it.
  • Relations between the moved collection and collections that stay in the old website become cross-website relations. Builder pages and in-page editing bindings of the old website no longer find the collection.