diff --git a/docs/apis/apis.md b/docs/apis/apis.md
new file mode 100644
index 0000000..d149933
--- /dev/null
+++ b/docs/apis/apis.md
@@ -0,0 +1,19 @@
+---
+sidebar_position: 1
+---
+
+# Data-Centric APIs
+
+Data-centric APIs are designed to provide a structured and standardized way to access and
+manipulate data. Unlike traditional APIs that focus on specific functionalities or services,
+data-centric APIs emphasize the data itself, making it easier to integrate, query, and manage data
+across different systems. These APIs often leverage semantic web technologies, such as RDF and SPARQL,
+to enable rich data interactions and ensure interoperability between diverse data sources.
+
+## Kopflos
+
+[Kopflos](./kopflos) is Zazuko's data-centric API platform that provides a flexible solution for managing and
+exposing data as APIs. The name, "Kopflos," is a German word that means "headless," reflecting the
+platform's focus on data rather than presentation. However, Kopflos is flexible enough to accommodate
+various data models and use cases, making it suitable for a wide range of applications, full-featured
+websites using the latest Web technologies.
diff --git a/docs/apis/kopflos/_category_.yml b/docs/apis/kopflos/_category_.yml
new file mode 100644
index 0000000..9706ee2
--- /dev/null
+++ b/docs/apis/kopflos/_category_.yml
@@ -0,0 +1,2 @@
+label: Kopflos
+position: 2
diff --git a/docs/apis/kopflos/explanations/_category_.yml b/docs/apis/kopflos/explanations/_category_.yml
new file mode 100644
index 0000000..c506892
--- /dev/null
+++ b/docs/apis/kopflos/explanations/_category_.yml
@@ -0,0 +1,2 @@
+label: Explanations
+position: 3
diff --git a/docs/apis/kopflos/explanations/request-pipeline.md b/docs/apis/kopflos/explanations/request-pipeline.md
new file mode 100644
index 0000000..8f6eb66
--- /dev/null
+++ b/docs/apis/kopflos/explanations/request-pipeline.md
@@ -0,0 +1,70 @@
+---
+title: Request pipeline
+sidebar_position: 1
+---
+
+# Kopflos request pipeline
+
+```
+Incoming Request
+  │
+  └─▶ Kopflos handler
+             │
+   4**/5** ◀─┴─▶ Resource Shape Lookup
+                   │
+         4**/5** ◀─┴─▶ Resource Loader Lookup
+                         │
+               4**/5** ◀─┴─▶ Load Resource
+                               │
+                         4** ◀─┴─▶ Authorization
+                                     │
+                               400 ◀─┴─▶ Validation
+                                           │
+                                 4**/5** ◀─┴─▶ (User handler)
+                                                 │
+                                                 └─▶ Reply
+```
+
+## Incoming request
+
+Incoming request is handled by the server library, such as express or fastify and then forwarded to Kopflos.
+
+## Kopflos handler
+
+Kopflos handler is the main entry point for all incoming requests. It is responsible for orchestrating the request pipeline.
+
+## Resource Shape Lookup
+
+Resource Shape Lookup executes SPARQL against the `default` query endpoint to find the shape targeting the requested resource.
+
+:::tip
+See also: [How to Select which resources should be served by the API](../how-to/resource-shape.md)
+:::
+
+## Resource Loader Lookup + Load Resource
+
+When the Resource Shape is found, a resource loader is selected based from `kopflos:resourceLoader` property, going bottom-up from the Resource/Property Shape to the share `kopflos:Config` resource.
+
+It is used to load the requested resource's Core Representation.
+
+:::info
+The Core Representation are the triples returned by the resource loader. Typically, that would be the result of a SPARQL `DESCRIBE` query or contents of resource's "own graph".
+:::
+
+:::warning
+By default, a loader which returns the resource's own graph is used.
+:::
+
+## Authorization
+
+Not implemented yet.
+
+## Validation
+
+Not implemented yet.
+
+## User handler
+
+Finally, the handler is executed. If no handler is defined, and the request method is a GET, the resource's Core Representation is returned.
+
+The result of the handler is forwarded back to the server library to be sent as a response.
diff --git a/docs/apis/kopflos/how-to/_category_.yml b/docs/apis/kopflos/how-to/_category_.yml
new file mode 100644
index 0000000..405427a
--- /dev/null
+++ b/docs/apis/kopflos/how-to/_category_.yml
@@ -0,0 +1,2 @@
+label: How-To
+position: 2
diff --git a/docs/apis/kopflos/how-to/express-middleware.md b/docs/apis/kopflos/how-to/express-middleware.md
new file mode 100644
index 0000000..d40b973
--- /dev/null
+++ b/docs/apis/kopflos/how-to/express-middleware.md
@@ -0,0 +1,87 @@
+# Use express middleware
+
+The package `@kopflos-cms/express` allows you to use existing express middleware in your Kopflos project.
+To do that, add a plugin `@kopflos-cms/express/middleware` to your `kopflos.config.js` file with `before`
+and `after` keys.
+
+The `after` middleware are only executed when kopflos handler returns a `404` status code or throws an error.
+
+## Middleware from NPM packages
+
+In your `kopflos.config.js` file, you can add references to other modules, such as `cors` or `compression`. 
+
+The requirements are that every such module default-exports a function which returns the actual middleware. 
+
+To provide an additional config, add a two element array instead of just the module name, as shown below
+on the example of `compression`.
+
+```javascript
+export default {
+  // ...other settings
+  plugins: {
+    '@kopflos-cms/express/middleware': {
+      before: [
+        'cors',      
+        ['compression', { level: 9 }],
+      ],
+    },
+  },
+}
+```
+
+You can also reference named exports by adding a `#name` after the modue name. For example, 
+to use [express-rate-limit](https://www.npmjs.com/package/express-rate-limit), you can do the following:
+
+```javascript
+export default {
+  // ...other settings
+  plugins: {
+    '@kopflos-cms/express/middleware': {
+      before: [
+        ['express-rate-limit#rateLimit', {
+          windowMs: 15 * 60 * 1000,
+          limit: 100,
+        }],      
+      ],
+    },
+  },
+}
+```
+
+## Your own middleware or NPM packages which do not export a function
+
+If you want to include your own middleware or a package which does not export a function, you can do so by
+exporting a function from your own module.
+
+```js
+// ./lib/my-middleware.js
+export default function myMiddleware() {
+  return (req, res, next) => {
+    // your middleware code here
+    next();
+  };
+}
+```
+
+Then, you can reference it in your `kopflos.config.js` file by the absolute path:
+
+```javascript
+import * as url from 'node:url'
+
+export default {
+  // ...other settings
+  plugins: {
+    '@kopflos-cms/express/middleware': {
+      before: [
+        url.fileURLToPath(new URL('./lib/my-middleware.js', import.meta.url)),
+      ],
+    },
+  },
+}
+```
+
+:::warning
+The path must be absolute, thus the usage of `import.meta.url` to resolve the path relative to the 
+config file itself. For that reason, this method will only work with configuration files written as
+code. (for commonjs, you can use `__dirname` instead)
+:::
diff --git a/docs/apis/kopflos/how-to/html-templates.md b/docs/apis/kopflos/how-to/html-templates.md
new file mode 100644
index 0000000..40c8576
--- /dev/null
+++ b/docs/apis/kopflos/how-to/html-templates.md
@@ -0,0 +1,170 @@
+# Serve RDF in data-bound HTML
+
+This guide will show you how to serve HTML templates bound to RDF data.
+
+:::warning
+These features are a work in progress.
+:::
+
+## Prerequisites
+
+In an existing kopflos application, install the following dependencies:
+
+```sh
+npm install @kopflos-labs/html-template @kopflos-labs/handlebars
+```
+
+## Create a template
+
+A template is a combination of HTML `<template>` elements and Handlebars expressions. It is
+important,
+however, that the HTML is only processed on the server and not in the browser. This is where the
+handlebars package comes in, providing a familiar syntax to fill in the templates with your data.
+
+First, create a new HTML file, for example `/templates/page.html` which will be used to serve a page
+with a title and a body simple. We will be serving instances of the `schema:Person` class.
+
+```html
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8">
+  <template target-class="schema:Person">
+    <template property="schema:name">
+      <title>{{ pointer.value }}</title>
+    </template>
+  </template>
+</head>
+<body>
+<template target-class="schema:Person">
+  <h1>{{ valueof schema:name }}</h1>
+
+  <template property="schema:address">
+    <dl>
+      <dt>Street</dt>
+      <dd>{{ valueof schema:streetAddress }}</dd>
+      <dt>City</dt>
+      <dd>{{ valueof schema:addressLocality }}</dd>
+      <dt>Postal Code</dt>
+      <dd>{{ valueof schema:postalCode }}</dd>
+    </dl>
+  </template>
+</template>
+</body>
+</html>
+```
+
+The template elements are used to find the correct data to fill in the placeholders.
+
+Similarly to [SHACL's `sh:targetClass`](https://www.w3.org/TR/shacl/#targetClass), the
+`target-class`
+attribute is used to find the root node in the template data. It is required on the top level
+template
+element.
+
+Templates with a `property` attribute are used to navigate the data graph, just like
+[Property Shapes](https://www.w3.org/TR/shacl/#property-shapes).
+
+Inside any template, you can use template binding expressions to fill in the data.
+
+:::tip
+Here we use handlebars, but it is possible to replace it with other templating languages.
+:::
+
+The current node in the data graph is available as `pointer`. The `valueof` helper is used to output
+value of a property, thus being an alternative to nested templates with `property` attributes.
+For example, since complex properties are supported,
+
+```html
+<img src="{{ valueof schema:image/schema:tumbnail/schema:contentUrl }}">
+``` 
+
+is a terser equivalent to:
+
+```html
+
+<template property="schema:image">
+  <template property="schema:thumbnail">
+    <template property="schema:contentUrl">
+      <img src="{{ pointer.value }}">
+    </template>
+  </template>
+</template>
+```
+
+## Create a page resource shape
+
+To serve the template, we need to create [Resource Shape](./resource-shape.md) which will
+act as a dynamic resource, meaning that it will serve resources which do no actually exist in the
+store. Instead, other resource data will be fetched and the page itself is only a URL pattern. In
+other words, a single resource shape will match and serve multiple resources.
+
+```turtle
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+PREFIX kl: <https://kopflos.described.at/>
+PREFIX code: <https://code.described.at/>
+
+<person-page>
+  a kl:ResourceShape ;
+  kl:api <> ;
+  sh:target
+    [
+      a kl:PatternedTarget ;
+      kl:regex "/page/person/(?<id>\\w+)$" ;
+    ] ;
+  kl:handler
+    [
+      a kl:Handler ;
+      kl:method "GET" ;
+      code:implementedBy
+        (
+          [
+            a code:EcmaScriptModule ;
+            code:link <node:@kopflos-cms/serve-file#default> ;
+            code:arguments ( "templates/person.html" ) ;
+          ]
+          [
+            a code:EcmaScriptModule ;
+            code:link <node:@kopflos-labs/html-template#default> ;
+            code:arguments
+              (
+                [
+                  a code:EcmaScriptModule ;
+                  code:link <node:@kopflos-labs/handlebars#default> ;
+                ]
+                [
+                  a code:EcmaScriptModule ;
+                  code:link <file:lib/templateData.js#describe> ;
+                ]
+                "/person/${id}"^^code:EcmaScriptTemplateLiteral
+              ) ;
+          ]
+        )
+    ] ;
+.
+```
+
+The patterned target is used to match the URL pattern similar to `/page/person/:id` where `:id` is
+stored as a [request subject variable](../reference/request-handlers#subject-variables).
+
+The handler is a sequence of modules which will load the template file using `@kopflos-cms/serve-file`
+and the process the templates using `@kopflos-labs/html-template` and `@kopflos-labs/handlebars`.
+
+## Create a data source
+
+Finally, you need to create the `lib/templateData.js#describe` module which will provide the data
+for the template:
+
+```ts
+import type { TemplateDataFunc } from '@kopflos-labs/html-template'
+
+export const describe = (resourcePath: string): TemplateDataFunc => ({ env }) => {
+  return env.sparql.default.stream.query.construct(`
+BASE <${env.kopflos.config.baseIri}>
+DESCRIBE <${resourcePath}>`)
+}
+```
+
+The implementation is a minimal query to describe the person resource, whose identifier is taken from
+the resource pattern. Notice how it's declaratively set in the handler as a template literal and
+forwarded to the `describe` function.
diff --git a/docs/apis/kopflos/how-to/load-api.md b/docs/apis/kopflos/how-to/load-api.md
new file mode 100644
index 0000000..f3ea31c
--- /dev/null
+++ b/docs/apis/kopflos/how-to/load-api.md
@@ -0,0 +1,34 @@
+# Load API description
+
+A Kopflos API is composed of triples that describe the API's structure and behavior. These triples need to be loaded into the API's store before the API can be used.
+
+## Load from named graphs
+
+The simplest and recommended way to load the API is to use named graphs. A single API can be loaded from multiple named graphs, and there can be multiple APIs served from a single Kopflos instance. Use the code below to load the API from named graphs:
+
+```js
+import Kopflos from '@kopflos-cms/core'
+
+let config
+const api = new Kopflos(config)
+await Kopflos.fromGraphs(api, 'http://example.com/api1', 'http://example.com/api2', 'http://example.com/shared')
+```
+
+:::tip
+[RDF/JS NamedNode](https://rdf.js.org/data-model-spec/#namednode-interface) objects can be used as well.
+:::
+
+The given named graphs will be loaded from the default SPARQL endpoint.
+
+## Initialise with preloaded data
+
+If you have the API triples in memory, you can initialise the API with it directly:
+
+```typescript
+import Kopflos from '@kopflos-cms/core'
+
+let config
+let dataset: DatasetCore
+
+const api = new Kopflos(config, { dataset })
+```
diff --git a/docs/apis/kopflos/how-to/parametrised-handlers.md b/docs/apis/kopflos/how-to/parametrised-handlers.md
new file mode 100644
index 0000000..d7e2567
--- /dev/null
+++ b/docs/apis/kopflos/how-to/parametrised-handlers.md
@@ -0,0 +1,80 @@
+# Implement parametrised handlers
+
+## Positional arguments
+
+It is possible to parametrise a handler so that it can be more easily adapted to various use cases.
+
+For example, a handler which runs queries could be configured to run against different
+endpoints configured in the app. To use such a handler, we can pass the endpoint as a parameter.
+That is done by adding a list or object of `code:arguments` property inside the implementation node. 
+
+```turtle
+PREFIX code: <https://code.described.at/>
+PREFIX kl: <https://kopflos.described.at/>
+
+[
+  a kl:Handler ;
+  code:implementedBy [
+    a code:EcamScriptModule ;
+    code:link <file:handler/query.js#runQuery> ;
+    code:arguments ( "wikidata" ) ;
+  ] ;
+] . 
+```
+
+The handler implementation can then access the arguments as a parameters passed to the handler factory.
+
+```ts
+// handler/query.js#runQuery
+import type { Handler } from '@kopflos-cms/core' 
+
+export function runQuery (endpointName: string): Handler {
+  return ({ env }) => {
+    const endpoint = env.sparql[endpointName]
+    if (!endpoint) {
+      throw new Error(`Unknown endpoint: ${endpointName}`)
+    }
+    
+    // Run the query against the endpoint
+  }
+}
+```
+
+## Named arguments
+
+Named arguments are also supported.
+
+```turtle
+PREFIX code: <https://code.described.at/>
+PREFIX arg: <https://code.described.at/argument#>
+PREFIX kl: <https://kopflos.described.at/>
+
+[
+  a kl:Handler ;
+  code:implementedBy [
+    a code:EcamScriptModule ;
+    code:link <file:handler/query.js#runQuery> ;
+    code:arguments [
+      arg:endpointName "wikidata" ;
+    ] ;
+  ] ;
+] . 
+```
+
+The handler implementation can then access the arguments as a parameters passed to the handler factory.
+
+```ts
+// handler/query.js#runQuery
+import type { Handler } from '@kopflos-cms/core' 
+
+export function runQuery ({ endpointName }): Handler {
+  return ({ env }) => {
+    const endpoint = env.sparql[endpointName]
+    if (!endpoint) {
+      throw new Error(`Unknown endpoint: ${endpointName}`)
+    }
+    
+    // Run the query against the endpoint
+  }
+}
+```
diff --git a/docs/apis/kopflos/how-to/patterned-target.md b/docs/apis/kopflos/how-to/patterned-target.md
new file mode 100644
index 0000000..6f35296
--- /dev/null
+++ b/docs/apis/kopflos/how-to/patterned-target.md
@@ -0,0 +1,60 @@
+# Serve virtual resources
+
+In addition to `sh:targetNode` and `sh:targetClass`, a specialised target can be used to match
+resources based on URL patterns. Such resources do not have to exist as triples in the database
+but can be generated on-the-fly by the server.
+
+For example, if you have a collection resource, such as `http://example.org/projects`, and you would
+like to implement pagination using URL query parameters, you can define a patterned target to match
+requests to `http://example.org/projects/1`, `http://example.org/projects/2`, etc.
+
+```turtle
+PREFIX code: <https://code.described.at/>
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+PREFIX kl: <https://kopflos.described.at/>
+
+[
+  a kl:ResourceShape ;
+  sh:target
+    [
+      a kl:PatternedTarget ;
+      # Capture the page number in the URL
+      kl:regex "/projects(/(?<page>\\d+))?" ;
+    ] ;
+  kl:handler
+    [
+      a kl:Handler ;
+      kl:method "GET" ;
+      code:implementedBy
+        [
+          a code:EcamScriptModule ;
+          code:link <file:handler/projects.js#getCollection> ;
+          # Pass the page number as an argument to the handler
+          code:arguments ( "${page}"^^code:EcmaScriptTemplateLiteral ) ;
+        ] ;
+    ] ;
+] .
+```
+
+:::tip
+The pattern is matched against the path part of the URL only.
+:::
+
+By taking advantage of named capture groups in the regular expression, you can extract parts of the
+URL. They can also be accessed programmatically from `subjectVariables` in a handler.
+
+```ts
+import { Handler } from '@kopflos-cms/core'
+
+export function getCollection (page: string): Handler {
+  return ({ subjectVariables }) => {
+    // subjectVariables.page === page
+  }
+}
+```
+
+:::warning
+Currently only regular expression patterns are supported. In a future release support for
+[RFC6570 URI templates](https://datatracker.ietf.org/doc/html/rfc6570) and express-style will be
+added.
+:::
diff --git a/docs/apis/kopflos/how-to/resource-loaders.md b/docs/apis/kopflos/how-to/resource-loaders.md
new file mode 100644
index 0000000..435de6a
--- /dev/null
+++ b/docs/apis/kopflos/how-to/resource-loaders.md
@@ -0,0 +1,139 @@
+# Configure resource loaders
+
+As explained on the [Request pipeline page](../explanations/request-pipeline.md), early in the request pipeline, Kopflos selects a resource loader to load the requested resource's Core Representation.
+
+Resource Loaders can be declared on instances of `kopflos:ResourceShape`, `kopflos:Api`, and `kopflos:Config` resources.
+
+## Predefined loaders
+
+Kopflos recognizes two loaders out of the box. They are identified by their shorthand identifiers.
+
+### Own graph loader
+
+The "Own Graph" loader is the default.
+It loads the named graph for the requested resource.
+For example,
+a request to `https://example.org/person/1` will load the entire named graph `https://example.org/person/1` as Core Representation.
+
+```turtle
+PREFIX kopflos: <https://kopflos.described.at/>
+
+<>
+  # a kopflos:ResourceShape ; # or
+  # a kopflos:Api ;           # or 
+  # a kopflos:Config ;
+  kopflos:resourceLoader kopflos:OwnGraphLoader ;
+.
+```
+
+### `DESCRIBE` loader
+
+The `DESCRIBE` loader is a built-in loader
+that uses the SPARQL `DESCRIBE` query to load the requested resource.
+The loader will issue a `DESCRIBE` query to the default SPARQL endpoint.
+
+```turtle
+PREFIX kopflos: <https://kopflos.described.at/>
+
+<>
+  # a kopflos:ResourceShape ; # or
+  # a kopflos:Api ;           # or 
+  # a kopflos:Config ;
+  kopflos:resourceLoader kopflos:DescribeLoader ;
+.
+```
+
+## Loader precedence
+
+Kopflos selects a loader based on the `kopflos:resourceLoader` property,
+going bottom-up from the Resource Shape to the shared `kopflos:Config` resource.
+
+```turtle
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+PREFIX kopflos: <https://kopflos.described.at/>
+PREFIX ex: <http://example.org/>
+
+ex:PersonShape
+  a kopflos:ResourceShape ;
+  kopflos:api ex:PeopleApi ;
+  sh:targetNode ex:Person ;
+  kopflos:resourceLoader ex:ResourceLoader1 ;
+.
+
+ex:AddressShape
+  a kopflos:ResourceShape ;
+  kopflos:api ex:PeopleApi ;
+  sh:targetNode ex:Person ;
+.
+
+ex:PeopleApi
+  a kopflos:Api ;
+  kopflos:config ex:Config ;
+  kopflos:resourceLoader ex:ResourceLoader2 ;
+.
+
+ex:ArticleShape
+  kopflos:api ex:PublishingApi ;
+  sh:targetNode ex:Article ;
+.
+
+ex:PublishingApi
+  a kopflos:Api ;
+  kopflos:config ex:Config ;
+.
+
+ex:Config
+  a kopflos:Config ;
+  kopflos:resourceLoader ex:ResourceLoader3 ;
+.
+```
+
+The algorithm is straightforward. For any given matched resource shape, Kopflos will:
+1. Check if the resource shape has a `kopflos:resourceLoader` property. If it does, Kopflos will use the loader specified in the property.
+2. If the resource shape does not have a `kopflos:resourceLoader` property, Kopflos will look for the `kopflos:resourceLoader` property in the resource's API resource.
+3. If the API resource does not have a `kopflos:resourceLoader` property, Kopflos will look for the `kopflos:resourceLoader` property in the linked `kopflos:Config` resource.
+
+In the example above:
+- If a requested resource matches the `ex:PersonShape`, Kopflos will use `ex:ResourceLoader1` from the resource shape itself.
+- If a requested resource matches the `ex:AddressShape`, Kopflos will use `ex:ResourceLoader2` from the API resource.
+- If a requested resource matches the `ex:ArticleShape`, Kopflos will use `ex:ResourceLoader3` from the Config resource.
+
+## Implementing and using custom Resource Loaders
+
+A loader is a function that takes the requested URI
+(in the form of a [NamedNode](https://rdf.js.org/data-model-spec/#namednode-interface))
+and returns a Core Representation as an [RDF/JS Stream](https://rdf.js.org/stream-spec/#stream-interface).
+It also takes a second argument: the instance of Kopflos that is processing the request.
+
+For example, here is a loader which sends a request query to a Stardog database,
+with a query hint to ensure that the Concise Bounded Description (CBD) is returned.
+
+```ts
+// src/resource-loaders/stardog-loaders.ts
+import type { ResourceLoader } from '@kopflos-cms/core'
+
+export const CBD: ResourceLoader = async (uri, kopflos) => {
+  const query = `
+#pragma describe.strategy cbd  
+DESCRIBE <${uri.value}>`
+  
+  return kopflos.env.sparql.default.stream.query.construct(query)
+}
+```
+
+To use it as the default in an API, declare the loader in the API's configuration:
+
+```turtle
+PREFIX code: <https://cube.link/code#>
+PREFIX kopflos: <https://kopflos.described.at/>
+PREFIX ex: <http://example.org/>
+
+ex:Config
+  a kopflos:Config ;
+  kopflos:resourceLoader
+    [
+      a code:EcmaScriptModule ;
+      code:link <file:src/resource-loaders/stardog-loaders.js#CBD> ;
+    ] ;
+.
+```
diff --git a/docs/apis/kopflos/how-to/resource-shape.md b/docs/apis/kopflos/how-to/resource-shape.md
new file mode 100644
index 0000000..040c1a8
--- /dev/null
+++ b/docs/apis/kopflos/how-to/resource-shape.md
@@ -0,0 +1,71 @@
+# Select which resources should be served by the API
+
+The central concept of the Kopflos is the `Resource Shape`. Its main purpose is to define which resources should be served by the API and how they should be served. Resource Shapes reuse some SHACL concepts.
+
+## Serving all instances of a class
+
+To have all instances of a class served by the API, define a shape that targets that class with `sh:targetClass`.
+
+```turtle
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+PREFIX kopflos: <https://kopflos.described.at/>
+PREFIX ex: <http://example.org/>
+
+<FooShape>
+  a kopflos:ResourceShape ;
+  sh:targetClass ex:Foo ;
+.
+
+<foo> a ex:Foo . # will be served by the API
+<bar> a ex:Foo . # will be served by the API
+<baz> a ex:Baz . # will not be served by the API
+```
+
+## Serving specific instances
+
+To serve only specific instances of a class, define a shape that targets those instances with `sh:targetNode`.
+
+```turtle
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+PREFIX kopflos: <https://kopflos.described.at/>
+PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
+
+<Shape>
+  a kopflos:ResourceShape ;
+  sh:targetNode <foo>, <bar> ;
+.
+
+<foo> rdfs:label "foo" . # will be served by the API
+<bar> rdfs:label "bar" . # will be served by the API
+<baz> rdfs:label "baz" . # will not be served by the API
+```
+
+## Serving objects of a property
+
+In some scenarios, it is useful to assign a specific handler to objects of a resource property. 
+
+To do so, define a shape that targets the property with `sh:property/sh:path` and assign a `kopflos:handler` to that Property Shape.
+
+```turtle
+PREFIX ex: <http://example.org/>
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+PREFIX kopflos: <https://kopflos.described.at/>
+PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
+
+<fooShape> 
+  a kopflos:ResourceShape ;
+  sh:targetClass ex:Foo ;
+  sh:property [
+    sh:path <foo#export> ;
+    kopflos:handler [
+      # ...
+    ] ;
+  ] ;
+.
+
+<foo>
+  a ex:Foo ;
+  <foo#export> <foo/export> ; # <foo/export> will be served by the API
+  <foo#import> <foo/import> ; # but <foo/import> will not
+.
+```
diff --git a/docs/apis/kopflos/how-to/seed-database.md b/docs/apis/kopflos/how-to/seed-database.md
new file mode 100644
index 0000000..848d2c4
--- /dev/null
+++ b/docs/apis/kopflos/how-to/seed-database.md
@@ -0,0 +1,55 @@
+# Seed database on app start
+
+When you start your app, you might want to seed the database with some initial data. This can be done
+by creating seed file(s) and configuring the plugin `@kopflos-cms/plugin-deploy-resources` to insert
+them into the database when the app starts.
+
+## Plugin configuration
+
+In your config, add the plugin with an array of `paths` relative to the working directory.
+
+```json
+{
+  "baseIri": "https://my-api.tech",
+  "plugins": {
+    "@kopflos-cms/plugin-deploy-resources": {
+      "paths": ["resources"]
+    }
+  }
+}
+```
+
+## Seed files
+
+The contents of the `resources` directory can be any RDF files. You can use relative URLs without 
+an explicit base URL. The plugin will parse the files using the app's configured `baseIri`. 
+
+Documents in formats which do not support graph, such as Turtle, will be inserted into individual
+named graphs.
+
+Dataset documents will insert their contents into graphs as they appear in the source. Default graph
+will be inserted into the named graph, like in the case of non-dataset formats.
+
+The extension of the files are excluded from the resulting graph names.
+
+A special name `index.[ext]` is handled similarly to how `index.html` is handled in a web server. For
+example, contents of `/foo/bar/index.ttl` will be inserted into the graph `https://my-api.tech/foo/bar`.
+
+### Concrete example 
+
+```
+resources/
+├── person/
+│   └── john-doe.ttl
+├── api.ttl
+└── schema.trig
+```
+
+The above will insert graphs:
+
+| source                | graph(s)                                                  |
+|-----------------------|-----------------------------------------------------------|
+| `person/john-doe.ttl` | `https://my-api.tech/person/john-doe`                     |
+| `api.ttl`             | `https://my-api.tech/api`                                 |
+| `schema.trig`         | `https://my-api.tech/schema` and/or explicit named graphs |
+```
diff --git a/docs/apis/kopflos/how-to/server-side-rendering.md b/docs/apis/kopflos/how-to/server-side-rendering.md
new file mode 100644
index 0000000..f967395
--- /dev/null
+++ b/docs/apis/kopflos/how-to/server-side-rendering.md
@@ -0,0 +1,238 @@
+# Render Web Components on the server
+
+This guide will show you how to serve server-side rendered content with Kopflos.
+
+The problem with Web Components is that styles and Shadow DOM which they encapsulate will only be
+applied after the components are loaded. This means that the page will be rendered incomplete at first
+and only finish rendering later. This is known as the flash of unstyled content (FOUC).
+
+By applying server-side rendering, we ensure that the content is available sooner to the user. This
+is especially important for search engine optimization.
+
+:::warning
+These features are a work in progress.
+:::
+
+## Prerequisites
+
+First, please make sure to follow the instructions in the [Getting Started](./html-templates.md)
+guide.
+
+Then, install the following dependencies:
+
+```sh
+npm install @kopflos-cms/vite @kopflos-labs/lit lit
+```
+
+## Loading web components in a page
+
+Web Components are a powerful way to encapsulate your UI components, making pages dynamic without
+sacrificing the declarative nature of HTML.
+
+Since they are just HTML, Kopflos can render any Web Components in the resulting HTML. However, not
+all Web Components are designed to be rendered on the server. Currently, Kopflos supports rendering
+[lit](https://lit.dev) components which follow the
+[Authoring components for Lit SSR](https://lit.dev/docs/ssr/authoring/) guide.
+
+Let's swap some plain HTML with lit components in the `/templates/page.html` file. For the sake of
+an
+example, these components will mainly encapsulate their styles.
+
+```html
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <!-- Code in head unchanged -->
+</head>
+<body>
+<template target-class="schema:Person">
+  <my-header level="1">{{ valueof schema:name }}</my-header>
+
+  <template property="schema:address">
+    <my-dl>
+      <dt>Street</dt>
+      <dd>{{ valueof schema:streetAddress }}</dd>
+      <dt>City</dt>
+      <dd>{{ valueof schema:addressLocality }}</dd>
+      <dt>Postal Code</dt>
+      <dd>{{ valueof schema:postalCode }}</dd>
+    </my-dl>
+  </template>
+</template>
+
+<script src="/page.js" type="module"></script>
+</body>
+</html>
+```
+
+In `page.js`, we only import the components.
+
+```js
+import './my-header.js';
+import './my-dl.js';
+```
+
+Below are the components.
+
+```js
+// my-header.js
+import { html, css, LitElement } from 'lit';
+
+class MyHeader extends LitElement {
+  static get styles () {
+    return css`
+      h1 {
+        color: red;
+      }
+    `;
+  }
+
+  static get properties () {
+    return {
+      level: { type: Number }
+    }
+  };
+
+  render () {
+    switch (this.level) {
+      case 1:
+        return html`<h1><slot></slot></h1>`;
+      case 2:
+        return html`<h2><slot></slot></h2>`;
+      case 3:
+        return html`<h3><slot></slot></h3>`;
+      default:
+        return html`<h4><slot></slot></h4>`;
+    }
+  }
+}
+
+customElements.define('my-header', MyHeader);
+```
+
+```js
+// my-dl.js
+import { html, css, LitElement } from 'lit';
+
+class MyDl extends LitElement {
+  static get styles () {
+    return css`
+      dl {
+        display: grid;
+        grid-template-columns: auto 1fr;
+        gap: 1em;
+      }
+    `;
+  }
+
+  render () {
+    return html`<dl><slot></slot></dl>`;
+  }
+}
+
+customElements.define('my-dl', MyDl);
+```
+
+Do refer to lit's documentation for more information on how to create components.
+
+## Preprocessing JS code
+
+Loaded from installed `node-modules`, Web Components cannot be imported directly in the browser.
+Also, some components might rely on APIs that are not available in the browser. Kopflos provides the
+package [`@kopflos-cms/vite`](../reference/modules/vite) to preprocess the JS code before serving it
+to the browser. It also provides a build functionality to produce optimized code for production.
+
+To use it, first add a vite plugin following to your `kopflos.config.js`:
+
+```js
+export default {
+  // existing config
+  plugins: {
+    '@kopflos-cms/vite': {
+      root: 'templates',
+      entrypoints: ['templates/*.html'],
+    },
+  },
+}
+```
+
+Then add a handler to the chain between `<node:@kopflos-cms/serve-file#default>` and
+`<node:@kopflos-labs/handlebars#default>`. This handler will preprocess the HTML so that JavaScript
+code is served by vite.
+
+```turtle
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+PREFIX kl: <https://kopflos.described.at/>
+PREFIX code: <https://code.described.at/>
+
+<person-page>
+  # ... abridged
+  kl:handler
+    [
+      a kl:Handler ;
+      kl:method "GET" ;
+      code:implementedBy
+        (
+          [
+            a code:EcmaScriptModule ;
+            code:link <node:@kopflos-cms/serve-file#default> ;
+            code:arguments ( "templates/person.html" ) ;
+          ]
+          [
+            a code:EcmaScriptModule ;
+            code:link <node:@kopflos-cms/vite/template.js#transform> ;
+          ]
+          [
+            a code:EcmaScriptModule ;
+            code:link <node:@kopflos-labs/html-template#default> ;
+            code:arguments
+              (
+                [
+                  a code:EcmaScriptModule ;
+                  code:link <node:@kopflos-labs/handlebars#default> ;
+                ]
+                [
+                  a code:EcmaScriptModule ;
+                  code:link <file:lib/templateData.js#describe> ;
+                ]
+                "/person/${id}"^^code:EcmaScriptTemplateLiteral
+              ) ;
+          ]
+        )
+    ] ;
+.
+```
+
+## Rendering on the server
+
+Finally, add another handler to the end of the chain.
+
+```turtle
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+PREFIX kl: <https://kopflos.described.at/>
+PREFIX code: <https://code.described.at/>
+
+<person-page>
+  # ... abridged
+  kl:handler
+    [
+      a kl:Handler ;
+      kl:method "GET" ;
+      code:implementedBy
+        (
+          # ... abridged
+          [
+            a code:EcmaScriptModule ;
+            code:link <node:@kopflos-labs/lit#ssr> ;
+            code:arguments
+              (
+                [ code:link <file:templates/my-header.js> ; a code:EcmaScriptModule ]
+              )
+          ]
+        )
+    ] ;
+.
+```
+
+By passing modules to the `ssr` function, Kopflos will render the components on the server. Here, we
+only `my-header`. The other component `my-dl` will only be running on the client.
diff --git a/docs/apis/kopflos/how-to/sparql-endpoints.md b/docs/apis/kopflos/how-to/sparql-endpoints.md
new file mode 100644
index 0000000..2ccbe7b
--- /dev/null
+++ b/docs/apis/kopflos/how-to/sparql-endpoints.md
@@ -0,0 +1,66 @@
+# Configure SPARQL endpoints
+
+Kopflos can be configured with one or more SPARQL endpoints which can be accessed at runtime by
+handler implementors. A single endpoint is required, named `default`.
+
+To configure the endpoints, one of three methods is supported.
+
+## From endpoint URL
+
+The simplest option is to provide a single unauthenticated endpoint URL which will be used for queries and updates.
+
+```js
+import Kopflos from '@kopflos-cms/core'
+
+let graph
+
+const kopflos = new Kopflos(graph, {
+  sparql: {
+    default: 'http://example.com/query',
+  }
+})
+```
+
+## From endpoint configuration object
+
+A more complex scenario will often require separate query and update URLs and authentication. In such
+cases, provide a full settings object as required by [`sparql-http-client`](https://github.com/rdf-ext/sparql-http-client).
+
+```js
+import Kopflos from '@kopflos-cms/core'
+
+let graph
+
+const kopflos = new Kopflos(graph, {
+  sparql: {
+    default: {
+      endpointUrl
+    }
+  }
+})
+```
+
+## Provide instances of SPARQL clients
+
+Lastly, it is possible to create the clients manually in code and pass them to Kopflos. 
+Both `stream` and `parsed` clients are required.
+
+```js
+import StreamClient from 'sparql-http-client'
+import ParsingClient from 'sparql-http-client/ParsingClient.js'
+import Kopflos from '@kopflos-cms/core'
+
+let graph
+
+const stream = new SparqlClient({ endpointUrl })
+const parsed = new ParsingClient({ endpointUrl })
+
+const kopflos = new Kopflos(graph, {
+  sparql: {
+    default: {
+      stream,
+      parsed
+    }
+  }
+})
+```
diff --git a/docs/apis/kopflos/how-to/web-server-libraries.md b/docs/apis/kopflos/how-to/web-server-libraries.md
new file mode 100644
index 0000000..58bfb7c
--- /dev/null
+++ b/docs/apis/kopflos/how-to/web-server-libraries.md
@@ -0,0 +1,25 @@
+# Integrate with web server libraries
+
+All libraries integrated with Kopflos require the same configuration, at the very least the SPARQL endpoint URL and the API graph URL(s).
+
+## Express
+
+```ts
+import express from 'express'
+import kopflos from '@kopflos-cms/express'
+
+const app = express()
+
+app.use(kopflos({
+  sparql: {
+    default: 'http://localhost:3030/ds/query',
+  },
+  apiGraphs: [
+    'https://example.com/api',
+  ]
+}))
+
+app.listen(3000, () => {
+  console.log('Server is running on http://localhost:3000')
+})
+```
diff --git a/docs/apis/kopflos/kopflos.md b/docs/apis/kopflos/kopflos.md
new file mode 100644
index 0000000..498651d
--- /dev/null
+++ b/docs/apis/kopflos/kopflos.md
@@ -0,0 +1,10 @@
+# Kopflos
+
+[Kopflos](https://github.com/zazuko/kopflos/) is Data-Centric API. Named "headless", it focuses on 
+RDF data and SPARQL but is flexible enough to accommodate various data models and use cases.
+
+Some key principles of Kopflos are:
+
+1. Provide a structured and standardized way to access and manipulate data.
+2. Emphasizes the data itself, making it easier to integrate, query, and manage data across different systems.
+3. Embed the API description in the data itself.
diff --git a/docs/apis/kopflos/reference/_category_.yml b/docs/apis/kopflos/reference/_category_.yml
new file mode 100644
index 0000000..4d35a5a
--- /dev/null
+++ b/docs/apis/kopflos/reference/_category_.yml
@@ -0,0 +1,2 @@
+label: Reference
+position: 3
diff --git a/docs/apis/kopflos/reference/cli.md b/docs/apis/kopflos/reference/cli.md
new file mode 100644
index 0000000..6bdc8a5
--- /dev/null
+++ b/docs/apis/kopflos/reference/cli.md
@@ -0,0 +1,37 @@
+# Command Line Interface
+
+Use `kopflos` to manage a Kopflos API.
+
+## `serve`
+
+Start the Kopflos API server.
+
+### `--config`
+
+Path to the [configuration file](./configuration.md).
+
+### `-m, --mode`
+
+Mode to run in (`development` or `production`). Default is `production`.
+
+### `--port`
+
+Port to listen on. Default is `1429`.
+
+### `--host`
+
+Host to listen on. Default is `0.0.0.0`.
+
+### `--trust-proxy`
+
+Configuring how the API trusts the `X-Forwarded-For` header. See [Express documentation](https://expressjs.com/en/guide/behind-proxies.html) for details. 
+
+Providing no value will be equivalent to `app.set('trust-proxy', true)`.
+
+### `--variable name=value`
+
+Provide overrides for configuration variables. Can be used multiple times.
+
+## `build`
+
+Executes `build` hooks from all plugins which implement it.
diff --git a/docs/apis/kopflos/reference/configuration.md b/docs/apis/kopflos/reference/configuration.md
new file mode 100644
index 0000000..7844152
--- /dev/null
+++ b/docs/apis/kopflos/reference/configuration.md
@@ -0,0 +1,92 @@
+# Configuration
+
+Kopflos can be configured via a configuration file, which can be in various formats and locations. If not provided, it will try various default locations:
+
+- `kopflos` key in `package.json`
+- `.kopflosrc` (YAML or JSON)
+- `.kopflosrc.(json|yaml|yml|js|ts|mjs|cjs)`
+- any of the above in `.config` directory
+- `kopflos.config.(js|ts|mjs|cjs)`
+
+## Structure
+
+```ts
+interface KopflosConfig {
+  mode?: 'development' | 'production'
+  // Base IRI for the API and all its resources
+  baseIri: string
+  // SPARQL endpoints. `default` endpoint is required.
+  sparql: {
+    default: string | import('sparql-http-client/StreamClient.js').Options
+    [key: string]: string | import('sparql-http-client/StreamClient.js').Options
+  }
+  // Named graphs which contain the API description.
+  apiGraphs: Array<NamedNode | string>
+  // Base path for resolving `code:link` imports
+  codeBase?: string
+  // Plugin configuration
+  plugins?: Record<string, unknown>
+  // Custom configuration variables
+  variables?: Record<string, unknown>
+}
+```
+
+## Variables
+
+Variables can additionally be provided via CLI options, and they will override the configuration
+file.
+
+```json
+{
+  "variables": {
+    "foo": "foo",
+    "bar": "bar"
+  }
+}
+```
+
+```sh
+kopflos --variable bar=baz
+```
+
+The above will result in the following variables:
+
+```json
+{
+  "foo": "foo",
+  "bar": "baz"
+}
+```
+
+They can be accessed from the KopflosEnvironment. In handler, for example:
+
+```ts
+import {Handler} from 'kopflos'
+
+export default (): Handler => ({env}) => {
+  const {foo, bar} = env.kopflos.config.variables
+}
+```
+
+They can also be used to parametrise handlers
+
+```turtle
+<#WebPage>
+  a kl:ResourceShape ;
+  kl:handler
+    [
+      a kl:Handler ;
+      kl:method "GET" ;
+      code:implementedBy
+        [
+          a code:EcmaScriptModule ;
+          code:link <file:handler/foobar.js#default> ;
+          code:arguments
+            (
+              "${foo}"^^code:EcmaScriptTemplateLiteral
+              "${bar}"^^code:EcmaScriptTemplateLiteral
+            ) ;
+        ] ;
+    ] ;
+.
+```
diff --git a/docs/apis/kopflos/reference/modules/_category_.yml b/docs/apis/kopflos/reference/modules/_category_.yml
new file mode 100644
index 0000000..db45674
--- /dev/null
+++ b/docs/apis/kopflos/reference/modules/_category_.yml
@@ -0,0 +1,2 @@
+label: Modules
+position: 1
diff --git a/docs/apis/kopflos/reference/modules/serve-file.md b/docs/apis/kopflos/reference/modules/serve-file.md
new file mode 100644
index 0000000..5d78578
--- /dev/null
+++ b/docs/apis/kopflos/reference/modules/serve-file.md
@@ -0,0 +1,69 @@
+# @kopflos-cms/serve-file
+
+Serves a file from the file system and sets `content-type` header based on the file extension.
+
+By default, will read the contents to memory.
+
+```turtle
+PREFIX code: <https://code.described.at/>
+PREFIX kl: <https://kopflos.described.at/>
+
+[
+  a kl:Handler ;
+  code:implementedBy
+    [
+      a code:EcamScriptModule ;
+      code:link <file:handler/serve-file.js#default> ;
+      code:arguments ( "/path/to/file" ) ;
+    ] ;
+] .
+```
+
+## Return file stream
+
+```turtle
+PREFIX arg: <https://code.described.at/argument#>
+PREFIX code: <https://code.described.at/>
+PREFIX kl: <https://kopflos.described.at/>
+
+[
+  a kl:Handler ;
+  code:implementedBy
+    [
+      a code:EcamScriptModule ;
+      code:link <file:handler/serve-file.js#default> ;
+      code:arguments
+        [
+          arg:path "/path/to/file" ;
+          arg:stream true ;
+        ] ;
+    ] ;
+] .
+```
+
+## Override content-type
+
+If the content type cannot be correctly determined from the file extension, 
+`application/octet-stream` will be used.
+
+You can override it, if necessary.
+
+```turtle
+PREFIX arg: <https://code.described.at/argument#>
+PREFIX code: <https://code.described.at/>
+PREFIX kl: <https://kopflos.described.at/>
+
+[
+  a kl:Handler ;
+  code:implementedBy
+    [
+      a code:EcamScriptModule ;
+      code:link <file:handler/serve-file.js#default> ;
+      code:arguments
+        [
+          arg:path "/path/to/file.xml" ;
+          arg:contenType "application/rdf+xml" ;
+        ] ;
+    ] ;
+] .
+```
diff --git a/docs/apis/kopflos/reference/modules/vite.md b/docs/apis/kopflos/reference/modules/vite.md
new file mode 100644
index 0000000..b84cd6a
--- /dev/null
+++ b/docs/apis/kopflos/reference/modules/vite.md
@@ -0,0 +1,40 @@
+# @kopflos-cms/vite
+
+## Plugin configuration
+
+```js
+export default {
+  plugins: {
+    "@kopflos-cms/vite": {
+      root: "ui",                  // required
+      entrypoints: ["ui/*.html"]   // required for build
+      configPath,                  // optional path to addtional vite config
+      outDir,                      // optional, default: "dist"
+    }
+  }
+}
+```
+
+## Template handler
+
+The handler transforms the HTML template so that JavaScript code is served by vite. It must be 
+preceded by another handler that serves the HTML, such as [@kopflos-cms/serve-file](./serve-file.md).
+
+```turtle
+PREFIX kl: <https://kopflos.described.at/>
+
+[
+  kl:handler
+    (
+      [
+        a code:EcmaScriptModule ;
+        code:link <node:@kopflos-cms/serve-file#default> ;
+        code:arguments ( "templates/person.html" ) ;
+      ]
+      [
+        a code:EcmaScriptModule ;
+        code:link <node:@kopflos-cms/vite/template.js#transform> ;
+      ]
+    )
+] .
+```
diff --git a/docs/apis/kopflos/reference/request-handlers.md b/docs/apis/kopflos/reference/request-handlers.md
new file mode 100644
index 0000000..42335e7
--- /dev/null
+++ b/docs/apis/kopflos/reference/request-handlers.md
@@ -0,0 +1,104 @@
+# Request handlers
+
+Depending on the kind of Resource Shape matched to the request, different arguments will be passed
+to the handler.
+
+## Subject handlers
+
+```turtle
+PREFIX kl: <https://kopflos.described.at/>
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+
+<#plaque>
+  a kl:ResourceShape ;
+  kl:api <> ;
+  sh:targetClass </api/schema/Plaque> ;
+.
+
+<#about>
+  a kl:ResourceShape ;
+  kl:api <> ;
+  sh:targetNode </about-page.html> ;
+.
+```
+
+The most common kind of request, when a resource is matched by its URL (`sh:targetNode`) or class (
+`sh:targetClass`).
+
+Such handlers will receive as the first argument an object in the form of this interface.
+
+```ts
+interface SubjectHandlerArgs {
+  resourceShape: GraphPointer<NamedNode, D>
+  env: KopflosEnvironment
+  subject: GraphPointer<NamedNode, D>
+  subjectVariables: Record<string, string>
+  body: Body<D>
+  query: Query
+  headers: IncomingHttpHeaders
+}
+```
+
+## Object handlers
+
+```turtle
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+PREFIX kl: <https://kopflos.described.at/>
+
+<#plaque>
+  a kl:ResourceShape ;
+  kl:api <> ;
+  sh:property
+    [
+      sh:path </api/schema/tags> ;
+      sh:handler
+        [
+          a kl:Handler ;
+          kl:method "GET" ;
+          # ...
+        ] ;
+    ] ;
+.
+```
+
+Requests matched to objects by following resource shape properties additionally receive the
+`predicate` and the `object`.
+
+```ts
+interface ObjectHandlerArgs extends SubjectHandlerArgs {
+  property: NamedNode
+  object: GraphPointer<NamedNode, D>
+}
+```
+
+:::warning
+Note that the `object` is the requested resource and the `subject` is the subject in the respective triple.
+This differs from subject handlers where the `subject` is the requested resource.
+:::
+
+## Subject variables
+
+Requests matched to a patterned target will fill the `subjectVariables` with values extracted from the URL pattern.
+
+```turtle
+PREFIX sh: <http://www.w3.org/ns/shacl#>
+PREFIX kl: <https://kopflos.described.at/>
+
+<person-page>
+  a kl:ResourceShape ;
+  kl:api <> ;
+  sh:target
+    [
+      a kl:PatternedTarget ;
+      kl:regex "/page/person/(?<id>.+)$" ;
+    ] ;
+.
+```
+
+Requesting `/page/person/123/abc` will result in the following `subjectVariables`:
+
+```json
+{
+  "id": "123/abc"
+}
+```
diff --git a/docs/cubes/cubes.md b/docs/cubes/cubes.md
index e54c97c..f687f13 100644
--- a/docs/cubes/cubes.md
+++ b/docs/cubes/cubes.md
@@ -4,4 +4,4 @@ sidebar_position: 1
 
 # RDF Data Cubes
 
-This sections contains information about practical usage of RDF Data Cubes represented with the [cube.link Cube Schema](https://cube.link/).
+This section contains information about practical usage of RDF Data Cubes represented with the [cube.link Cube Schema](https://cube.link/).
diff --git a/docusaurus.config.mjs b/docusaurus.config.mjs
index 62cfa01..93dae53 100644
--- a/docusaurus.config.mjs
+++ b/docusaurus.config.mjs
@@ -83,6 +83,12 @@ const config = {
             position: 'left',
             label: 'Workflows',
           },
+          {
+            type: 'docSidebar',
+            sidebarId: 'apisSidebar',
+            position: 'left',
+            label: 'APIs',
+          },
           {
             type: 'docSidebar',
             sidebarId: 'cubesSidebar',
@@ -142,7 +148,7 @@ const config = {
       prism: {
         theme: themes.nightOwlLight,
         darkTheme: themes.nightOwl,
-        additionalLanguages: ['turtle', 'sparql'],
+        additionalLanguages: ['turtle', 'sparql', 'json'],
       },
     }),
 };
diff --git a/sidebars.js b/sidebars.js
index 748a193..3bff4d3 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -17,6 +17,7 @@ const sidebars = {
   aboutSidebar: [{ type: 'autogenerated', dirName: 'about' }],
   rdfjsSidebar: [{ type: 'autogenerated', dirName: 'rdfjs' }],
   workflowsSidebar: [{ type: 'autogenerated', dirName: 'workflows' }],
+  apisSidebar: [{ type: 'autogenerated', dirName: 'apis' }],
   cubesSidebar: [{ type: 'autogenerated', dirName: 'cubes' }],
   appsSidebar: [{ type: 'autogenerated', dirName: 'apps' }],
 
diff --git a/src/components/HomepageFeatures/index.tsx b/src/components/HomepageFeatures/index.tsx
index 2965176..3a33f31 100644
--- a/src/components/HomepageFeatures/index.tsx
+++ b/src/components/HomepageFeatures/index.tsx
@@ -31,9 +31,19 @@ const FeatureList: FeatureItem[] = [
     ),
   },
   {
-    page: "/docs/cubes/",
-    title: "Cubes",
-    image: "/img/cube.png",
+    page: '/docs/apis/',
+    title: 'APIs',
+    image: '/img/kopflos.png',
+    description: (
+      <>
+        Simply create APIs for your data-centric applications
+      </>
+    ),
+  },
+  {
+    page: '/docs/cubes/',
+    title: 'Cubes',
+    image: '/img/cube.png',
     description: (
       <>Use cube.link Cube Schema to create and manage RDF data cubes</>
     ),
diff --git a/static/img/kopflos.png b/static/img/kopflos.png
new file mode 100644
index 0000000..ae764e2
Binary files /dev/null and b/static/img/kopflos.png differ