API reference pages

If you publish API documentation, you can mark a page as an endpoint reference by giving it an API endpoint: an HTTP method optionally followed by a path, like GET /pages/{slug}.

On a page with an API endpoint, the title gets a colored method badge in the sidebar navigation, so a reference section scans like an API index.

With badges carrying the method, page titles can be verbs instead of routes: “List pages” rather than “GET /pages”. The badge says what kind of request it is; the title says what it does.

Setting it

In the dashboard, the API endpoint is a field in the page editor’s Metadata section. Leave it empty for a normal page; clearing it turns a reference page back into a normal one.

Through the API, set apiEndpoint on the page object:

{
  "pages": [
    {
      "slug": "list-pages",
      "title": "List pages",
      "content": "List all pages for a site.",
      "apiEndpoint": "GET /pages"
    }
  ]
}

In Markdown published through the GitHub Action or the Obsidian plugin, set api_endpoint in front matter — pasting such a file into the dashboard editor fills the field the same way:

---
title: List pages
api_endpoint: GET /pages
---

# List pages

List all pages for a site.

The value must start with GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS (case doesn’t matter — the method is uppercased on save). The path is free-form text, typically relative to your API’s base URL, and can be omitted for a method-only badge.

Structuring a reference

A typical layout uses a standalone section per resource, one page per endpoint:

Concept pages like an overview or authentication guide simply have no API endpoint and sit alongside the endpoint pages.