Kwisple is one platform for a client's whole digital presence: website content, brand kit, social calendar, statistics, forms and requests. An agency runs it for its clients. For you as a developer the short version is: the website is your code, in your repository; the platform is the CMS, the delivery API, the hosting glue and the dashboard around it.
This page explains the model you build against. If you want to start typing right away, go to the quick start and come back later.
The platform model
platform (admin users)
└── agency reseller: agency, studio or freelancer · white-label branding
└── workspace one client · all content tables carry workspace_id- Platform: one deployment for everybody. Adding a client is a database row, never a new deploy.
- Agency: the team side. Agency members open every workspace of their agency. The agency's branding replaces the product identity for its clients (white-label), optionally on the agency's own dashboard host.
- Workspace: one client. Every tenant table carries a
workspace_id; every query on the platform goes through a helper that requires it. Client users are members of a workspace and see only that workspace.
When you work in the dashboard you do so as a member of the agency team. Linking a site repository, pushing a content model and creating API tokens need the agency's developer right (site.advanced); deploy settings need site.deploy. A client's own developer joins the agency team or asks the agency to link the site (see Tenancy and permissions for the whole access model).
What the platform provides, and what lives in your repository
| The platform provides | Your site repository owns |
|---|---|
| The CMS: entries, sections, globals, drafts, revisions, trash, redirects and the 404 log, edited in the dashboard with live preview | All code: templates, components, styling, animations, routing |
The delivery API (/api/v1/*) and the typed SDK client that reads from it | The design: how every entry type and every block renders |
| Assets: uploads with alt text, focal point and blur placeholder, served from the platform's storage origin | The content model as code (cms.config.ts), pushed to the platform |
| Forms: submissions, spam filtering, booking slots, confirmation mails, a follow-up status per submission | Custom modules (booking desks, generators, calculators), shown in the client's dashboard as apps |
| Statistics: cookieless visitor counts, per block, including AI-agent visits, and the generated cookie banner | Your own build pipeline, tests and CI |
The brand kit: colours, fonts, logos and voice, delivered as --brand-* CSS variables and font preloads | The Docker image or host configuration that runs the site |
| Requests: the client's wish list and the Websitecheck's code suggestions reach the agency as requests | |
| Hosting glue: repository connection, deploy status, PR previews, a staging environment, domains and DNS checks |
The platform never renders a custom site. It stores and serves content; your code fetches it (server-side, with a site token) and renders it. There are no database dumps: locally you read the platform's content directly, with a token kwisple link writes to .env.
The content model follows Craft CMS: fields, entry types, sections (single, channel, structure), Matrix blocks and global sets, written in TypeScript in cms.config.ts. Types come from that file, without code generation. Schema as code and Coming from Craft CMS go into detail.
The three site modes
Every website in the dashboard has a mode:
| Mode | Dashboard label | What it is | For new sites? |
|---|---|---|---|
headless | Eigen code / Op maat (eigen code) (custom code) | Custom code in its own repository (Astro or Next.js) with @kwisple/sdk, reading from the delivery API. The platform knows its URL, preview URL and webhook URL. | Yes. The only mode offered for new websites. |
hosted | Bouwblokken / Gehoste site (blokken) (building blocks) | Legacy block sites rendered by the platform's own renderer with a standard content model. Existing ones keep working. | No. Never offered for new sites. |
external | Beheerd in … (managed in another platform) | A site built elsewhere (Craft, WordPress, …). The platform keeps its URL and admin link so social posts, QR codes and signatures use the right address. The platform never serves it. | Only for existing external sites. |
Everything in this documentation is about headless sites unless it says otherwise. Only headless sites can be linked with kwisple link, connected to a repository, given a staging environment or extended with apps.
A headless site can also have an environment: production (the default) or staging. A staging environment is a site of its own, with its own content, token and deployment of the staging branch. See Staging.
What you get for free
The SDK and the starters set these up so you do not have to:
- Live preview for editors: the dashboard opens your site's
/api/previewroute in an iframe; drafts render in place and refresh after every autosave (Live preview and revalidation). - Caching that refreshes itself: pages are cached (Next data cache / ISR, or Astro's in-memory cache) and purged by a signed webhook after every publish.
- Images in AVIF and WebP with focal point, blur placeholder and a width ladder that never upscales (Rendering content).
- SEO: title, description, canonical, hreflang, Open Graph, sitemap, robots and JSON-LD helpers (SEO, performance and security headers).
- Forms through the forms API, with honeypot and timing checks, booking slots and confirmation mails (Forms, bookings and confirmations).
- Statistics and consent: cookieless statistics and a cookie banner configured in the dashboard (Statistics and consent).
- Redirects and 404s: URI changes create redirects automatically; your 404 page reports to the dashboard's 404 log, where the agency can add a redirect with one click.
The starters score Lighthouse 95+ on performance and 100 on accessibility, best practices and SEO on a production build, and pnpm lighthouse in the platform repository guards that.
"AI assists, never leads"
The platform holds no model API keys. Assistant features run through the agency's own agent, and the agent only proposes. For you this means:
- Proposals, never published content. The assistant can propose field values for an entry, alt texts, captions or a new page as an offline draft. A person accepts or edits them in the dashboard. Your site only ever renders what a person published; nothing in your code has to distinguish AI-written content.
- No AI in the render path. Your site never calls a model. Everything the SDK fetches is content, brand or configuration.
- Websitecheck tasks for the developer. The monthly Websitecheck reads the statistics and the page texts and proposes improvements. Text proposals go to the editor. Code suggestions appear under Aanpassingen door … (changes by the agency) and the client chooses Vraag aan … (ask the agency) or Niet nodig (not needed). A requested change reaches the agency as a request under Verzoeken, with the proposal's reasoning. That request is your work item: a new block, a technical fix, a redirect. The platform never changes code by itself.
- The brand is never AI-generated. Colours, fonts, logos and voice are set by people in the brand kit; your site reads them through
client.brand().
Where to go next
- Quick start: five minutes to live content: create a site, log in, link it, run it.
- Concepts: short definitions of everything you will meet, with links.
- Project structure (Next.js) or Project structure (Astro): every file of the starter explained.
- Schema as code: the content model.
- Hosting and deploys, Staging and Domains and DNS: going live.
- Apps overview: custom modules for one client, inside their dashboard.
- Working on the platform itself: Monorepo overview.