k.groups
Declare the groups routes are organised into, nested as deep as the API needs.
Declare the groups routes are organised into. Name the result under groups on defineConfig, and declare routes into a group with k.routes.
Parameters
Each entry is keyed by a name you choose. A value is either a GroupOptions object or a plain title string:
| Option | Type | Required | Description |
|---|---|---|---|
title | string | Yes | The group's name in the docs. Unique among its siblings |
description | string | No | Shown beside the tag in the OpenAPI document |
externalDocs | object | No | { url, description? } external docs for the group |
groups | object | No | The groups nested under this one, in the same shape |
A group is addressed by its dotted path, workspaces.members. k.groups throws when two siblings share a title, since a reader could not tell them apart.
Returns
A GroupSet. Once your Config carries it, k.routes offers every group by name, and a route's own groups completes their dotted paths. The generated OpenAPI document lists each top-level group as a tag.
Example
The group is also the route's key: listMembers is workspaces.members.listMembers, so clients call routes where the documentation files them. List the trees on defineConfig in any order, routes: [memberRoutes, inviteRoutes]. kizuna routes fails when a route is in no group once groups exist, and when a group holds no routes.
Nested groups in OpenAPI
OpenAPI 3.1 has no nested tags, so each top-level group becomes a tag and a route in a nested group is listed under the group at the top of its path. listMembers shows under Workspaces.
A title only has to differ from its siblings, since nested titles never become tags of their own. workspace.notes and assistant.notes can both be titled "Notes".
Listing a route under more groups
A route's own groups adds it to more groups, by dotted path, with completion:
See the Routes guide for laying groups out across files.