@eventcatalog/core 5.1.1 → 5.2.1

package/dist/docs/development/export/03-custom-exports.md

@@ -0,0 +1,257 @@
+---
+sidebar_position: 3
+keywords:
+- EventCatalog custom exports
+- Partner documentation
+- Public architecture documentation
+- Export part of a catalog
+- Include and exclude resources
+sidebar_label: Custom exports
+title: Custom exports
+description: Export the part of your catalog you choose for partners, a regulator or another team, as one HTML file with your own introduction.
+---
+
+import AddedIn from '@site/src/components/MDX/AddedIn';
+
+<AddedIn version="5.2.0" />
+
+The [architecture reference](/docs/development/export/architecture-reference) has your whole catalog in it, which is right for your own teams. For people outside them you usually want **part** of it: the services and events a partner integrates with, without the internal workers, databases and owners around them.
+
+A **custom export** is that part of your catalog, written as a file in your catalog. Its frontmatter says what's in it, and its body is the introduction readers see first. Each one is written as its own HTML file, in the same format as the reference.
+
+![A custom export for partners, with its title, audience, introduction and contents, and only the system, services, events and command it includes in the sidebar](./img/custom-export.png)
+
+Some custom exports you might write:
+
+- **For partners**: the services, events and specifications they integrate with.
+- **For a regulator or a data protection review**: every resource that holds personal data.
+- **For the team taking over a domain**: the whole domain, with its owners and docs.
+- **For the public**: whatever your resources mark as public, with a [custom property](#by-custom-property) such as `x-public: true`.
+
+## Create a custom export
+
+Add a file to the `exports` folder at the root of your catalog. The file name is the export's id: `exports/partner-payments.mdx` is the export `partner-payments`, written to `partner-payments.html`.
+
+```mdx title="exports/partner-payments.mdx"
+---
+title: Payments for partners
+summary: How partners take payment for orders and stay in sync with what happens next.
+audience: Partners integrating with Acme Checkout
+version: 2026.10
+
+include:
+  # A whole system: its services, data stores and the messages they send and receive
+  - system: payment-processing-system
+  # One service, at the version partners integrate with
+  - service: checkout-api
+    version: 1.x
+  # Single messages
+  - event: payment-succeeded
+  - event: payment-failed
+  - event: refund-processed
+
+exclude:
+  # Internal, even though it's in the system above
+  - service: payment-worker
+  - data-store: payment-database
+  # Anything holding personal data, by its custom property
+  - x-contains-personal-data: true
+---
+
+Welcome! This guide covers everything you need to take payment for an Acme order and react to what happens afterwards.
+
+## How it works
+
+1. Your app checks out a cart through the [[service|checkout-api]].
+2. You receive [[event|payment-succeeded]] or [[event|payment-failed]], then [[event|refund-processed]] if the order is refunded later.
+```
+
+`title` and `include` are required. `summary`, `audience` and `version` are shown at the top of the page. The body is markdown, and can link to resources with `[[type|id]]`, as your other pages do.
+
+See the [reference](/docs/development/export/reference#frontmatter) for every field.
+
+## Choose what's in it
+
+`include` and `exclude` are lists of **selectors**. A selector names one resource by its kind and id, or matches every resource with a [custom property](/docs/development/customization/custom-properties).
+
+### By id
+
+```yaml
+include:
+  - domain: payments
+  - system: payment-processing-system
+  - service: checkout-api
+    version: 1.x # optional: an exact version or a range
+  - event: payment-succeeded
+  - message: refund-requested # an event, command or query with this id
+```
+
+Only the latest version of each resource is exported, so a `version` must match the latest one. If it doesn't, [checking the export](#check-a-custom-export) tells you which version is exported. See the [reference](/docs/development/export/reference#selectors) for every kind you can select.
+
+### By custom property
+
+Any selector with an `x-` field matches every resource with that custom property, instead of one resource:
+
+```yaml
+include:
+  # Every resource with x-public: true
+  - x-public: true
+  # Tier 1 services only
+  - x-operational-tier: 1
+    kind: service
+  # Any of these values
+  - x-data-classification: [public, partner]
+exclude:
+  - x-internal: true
+```
+
+- Every `x-` field in a selector must match. Separate selectors are alternatives.
+- A field matches when the resource's value is one of those given. Values are compared as text, so `true` matches `true` and `"true"`.
+- When a resource's value is a list, it matches when any item in it does.
+- Objects can't be matched.
+- `kind` narrows the selector to one kind of resource, or a list of them (`kind: [service, event]`).
+
+This lets resources opt in from their own frontmatter: mark what partners may see with `x-public: true`, and one selector picks it all up, including whatever you mark later.
+
+The custom properties choose what's in an export, but they're never shown in it. Values like `x-cost-centre` stay in your catalog.
+
+### What include brings in
+
+| You include | What goes in the export |
+| --- | --- |
+| A domain | The domain, its subdomains, systems, services, entities and flows, all the way down, and the messages its services send and receive |
+| A system | The system, its services, data stores, entities and flows, and the messages its services send and receive |
+| Anything else | That resource |
+
+A service on its own doesn't bring its messages. Include them, include the system the service is in, or set `references: include`.
+
+### Exclude
+
+`exclude` is applied first and always wins over `include`.
+
+- A resource you exclude isn't added, even when it's inside something you included.
+- Excluding a domain or system takes out everything in it.
+- An excluded resource brings nothing with it. The messages only an excluded service sends and receives aren't pulled in through it.
+- **An excluded resource is never named**. Links to it are dropped, whatever `references` is set to, and links to it in docs read "another service".
+
+### Never export {#never-export}
+
+`neverExport` in `eventcatalog.config.js` works like an `exclude` in every custom export. Use it for what must never leave your catalog, whatever an export includes. It takes the same selectors, by id or by custom property:
+
+```js title="eventcatalog.config.js"
+module.exports = {
+  exports: {
+    custom: {
+      neverExport: [
+        { service: 'fraud-detection' },
+        { 'x-data-classification': ['confidential', 'restricted'] },
+      ],
+    },
+  },
+};
+```
+
+### Links to resources outside the export
+
+Resources in the export still point at things that aren't in it, like a service that consumes one of your events. `references` sets what readers see:
+
+- `omit` (the default): nothing. The link is dropped.
+- `name-only`: the resource's name, without a link.
+- `include`: the resource itself, pulled into the export. One level only, so what it points at isn't followed. Excluded resources are never pulled in.
+
+### Hidden fields
+
+Some fields are written for your own teams. By default, an export leaves out the owners, repositories, team contacts and the resources' own docs. Set `hide` to choose:
+
+```yaml
+hide: [owners, repository] # show contacts and docs
+```
+
+Set `hide: []` to show everything, for example in an export for one of your own teams. See the [reference](/docs/development/export/reference#hide) for every field you can hide.
+
+The resources' docs are hidden by default because they're often full of what's around them. If you show them, links in them to resources outside the export read "another service", "another event" and so on (or the resource's name, with `references: name-only`, unless it was excluded).
+
+### The order things happen in
+
+1. `exclude` and `neverExport` take resources out, with everything inside them.
+2. `include` adds what it names (a domain or system with what's inside it), skipping anything taken out.
+3. `references: include` adds what those resources point at, one level.
+4. Links to anything outside the export are dropped, or shown as names with `references: name-only`.
+5. `hide` leaves fields out of what's left.
+
+## Check a custom export
+
+Before you share a custom export, check what's in it, what was left out, and why:
+
+```bash
+npx @eventcatalog/cli export partner-payments --check
+```
+
+```
+  Payments for partners (exports/partner-payments.mdx)
+
+  Included (7)
+    system   payment-processing-system 1.0.0  (include)
+    service  payment-api 1.0.0                (in system payment-processing-system)
+    command  authorize-payment 1.0.0          (in system payment-processing-system)
+    service  checkout-api 1.0.0               (include)
+    event    payment-succeeded 1.0.0          (include)
+    event    payment-failed 1.0.0             (include)
+    event    refund-processed 1.0.0           (include)
+
+  Excluded (2)
+    service     payment-worker 1.0.0    (exclude, was in system payment-processing-system)
+    data store  payment-database 1.0.0  (exclude, was in system payment-processing-system)
+
+  Links dropped (26)
+    system payment-processing-system  →  domain payments  (not in this export)
+    ...
+
+  Hidden: owners, repository, contacts, docs
+```
+
+Resources matched by a custom property say so, for example `(include service with x-operational-tier: 1)`.
+
+`--check` fails when a selector in `include` or `exclude` matches nothing in the catalog, so run it in CI to notice when a resource is renamed or removed.
+
+## Export it
+
+**Every time you build your catalog**, EventCatalog writes each custom export to `dist/exports/<id>.html` (`dist/client/exports/<id>.html` in [server mode](/docs/development/deployment/build-ssr-mode)). Wherever you host your catalog, it's at `/exports/<id>.html`.
+
+Each one is written on its own: a custom export with a problem is skipped with a warning in the build's output, and the others are still written. Run [`--check`](#check-a-custom-export) on it to see what's wrong.
+
+To export one without building the catalog, use the CLI:
+
+```bash
+npx @eventcatalog/cli export partner-payments
+```
+
+This writes `partner-payments.html` and opens it in your browser. See the [reference](/docs/development/export/reference#cli) for the CLI's options.
+
+## Configure custom exports
+
+Set options for every custom export in `eventcatalog.config.js`, under `exports.custom`:
+
+```js title="eventcatalog.config.js"
+module.exports = {
+  exports: {
+    custom: {
+      // Build only these custom exports (by id)
+      only: ['partner-payments'],
+      // What every custom export starts from. Its own frontmatter overrides it.
+      defaults: {
+        hide: ['owners', 'repository', 'contacts', 'docs'],
+        references: 'omit',
+      },
+      // Never in any custom export, whatever it includes
+      neverExport: [{ 'x-data-classification': ['confidential', 'restricted'] }],
+    },
+  },
+};
+```
+
+To stop writing custom exports when you build, set `exports.custom.enabled` to `false`.
+
+If your catalog uses [authentication](/docs/development/authentication/introduction), custom exports aren't written when you build unless you set `exports.custom.enabled` to `true`. You can still export them with the CLI.
+
+See the [reference](/docs/development/export/reference#configuration) for every option.

package/dist/docs/development/export/04-reference.md

@@ -0,0 +1,383 @@
+---
+sidebar_position: 4
+keywords:
+- EventCatalog export
+- Custom export frontmatter
+- Export configuration
+- Export CLI
+sidebar_label: Reference
+title: Export reference
+description: Paths, frontmatter fields, selectors, configuration, CLI options and APIs for the architecture reference and custom exports.
+---
+
+import AddedIn from '@site/src/components/MDX/AddedIn';
+
+Everything about exporting your catalog in one place: the [architecture reference](/docs/development/export/architecture-reference) and [custom exports](/docs/development/export/custom-exports).
+
+## Paths {#paths}
+
+Custom exports are files in the `exports` folder at the root of your catalog, one per export:
+
+```txt
+/exports/{id}.mdx
+/exports/{id}.md
+```
+
+The folder isn't searched recursively. Set [`exports.custom.dir`](#exports-custom) to use another folder.
+
+## Output {#output}
+
+| File | Static build | [Server mode](/docs/development/deployment/build-ssr-mode) | Hosted at |
+| --- | --- | --- | --- |
+| Architecture reference | `dist/architecture.html` | `dist/client/architecture.html` | `/architecture.html` |
+| Custom export | `dist/exports/{id}.html` | `dist/client/exports/{id}.html` | `/exports/{id}.html` |
+
+The [CLI](#cli) writes `architecture.html` or `{id}.html` in the folder you run it from, unless you pass `--output`.
+
+Every file is self-contained: styles, scripts, schemas and specifications are inside it. Only the latest version of each resource is exported.
+
+## Frontmatter {#frontmatter}
+
+The frontmatter of a custom export file. Any other field is an error, and every problem in a file is reported at once.
+
+Values are read as text, so `version: 2026.10` stays `2026.10`.
+
+### Required fields
+
+#### `title` {#title}
+
+- Type: `string`
+
+The export's title, shown at the top of the page and in link previews.
+
+```md title="Example"
+---
+title: Payments for partners
+---
+```
+
+#### `include` {#include}
+
+- Type: `array` of [selectors](#selectors)
+
+What's in the export. A domain or system brings what's inside it.
+
+```md title="Example"
+---
+include:
+  - system: payment-processing-system
+  - event: payment-succeeded
+  - x-public: true
+---
+```
+
+### Optional fields
+
+#### `id` {#id}
+
+- Type: `string`
+- Default: the file name, without its extension
+
+The export's id. It names the HTML file and is what you pass to the CLI. Letters, numbers, `-` and `_` only, and unique across the folder.
+
+```md title="Example"
+---
+id: payments-for-partners
+---
+```
+
+#### `summary` {#summary}
+
+- Type: `string`
+
+A sentence under the title. Also used as the description in link previews.
+
+```md title="Example"
+---
+summary: How partners take payment for orders and stay in sync with what happens next.
+---
+```
+
+#### `audience` {#audience}
+
+- Type: `string`
+
+Who the export is for, shown under the title.
+
+```md title="Example"
+---
+audience: Partners integrating with Acme Checkout
+---
+```
+
+#### `version` {#version}
+
+- Type: `string`
+
+The export's own version, shown at the top of the page.
+
+```md title="Example"
+---
+version: 2026.10
+---
+```
+
+#### `exclude` {#exclude}
+
+- Type: `array` of [selectors](#selectors)
+
+What to take out again. Applied before `include`, and always wins. Excluding a domain or system takes out everything in it, and an excluded resource is never named in the export.
+
+```md title="Example"
+---
+exclude:
+  - service: payment-worker
+  - x-internal: true
+---
+```
+
+#### `references` {#references}
+
+- Type: `omit`, `name-only` or `include`
+- Default: `omit`, or [`exports.custom.defaults.references`](#exports-custom)
+
+What to show for links to resources that aren't in the export:
+
+| Value | What's shown |
+| --- | --- |
+| `omit` | Nothing. The link is dropped. |
+| `name-only` | The resource's name, without a link. |
+| `include` | The resource itself, pulled into the export. One level only: what it points at isn't followed. |
+
+Links to excluded resources are always dropped.
+
+```md title="Example"
+---
+references: name-only
+---
+```
+
+#### `hide` {#hide}
+
+- Type: `array`
+- Default: `[owners, repository, contacts, docs]`, or [`exports.custom.defaults.hide`](#exports-custom)
+
+Fields to leave out of every resource in the export. Set `hide: []` to show everything.
+
+| Value | What it leaves out |
+| --- | --- |
+| `owners` | Who owns each resource, and what each team or user in the export owns |
+| `repository` | Where a service's code lives |
+| `contacts` | Team and user email addresses and Slack channels |
+| `docs` | The resources' own documentation (the body of their pages) |
+| `specifications` | OpenAPI, AsyncAPI and GraphQL specifications |
+| `examples` | Example payloads for messages, including the one made from the schema |
+
+```md title="Example"
+---
+hide: [owners, repository]
+---
+```
+
+### Body
+
+The body of the file is the export's introduction, in markdown, shown before the resources. It can link to resources with `[[type|id]]`. A link to a resource that isn't in the export reads "another service", "another event" and so on, or the resource's name with `references: name-only` (unless it was excluded).
+
+## Selectors {#selectors}
+
+`include`, `exclude` and [`neverExport`](#exports-custom) are lists of selectors.
+
+### By id
+
+One resource, by its kind and id, with an optional version:
+
+```yaml
+- service: checkout-api
+  version: 1.x
+```
+
+| Key | Matches |
+| --- | --- |
+| `domain` | A domain, with its subdomains, systems, services, entities and flows, and the messages its services send and receive |
+| `system` | A system, with its services, data stores, entities and flows, and the messages its services send and receive |
+| `service` | A service, or an agent with that id when no service has it |
+| `agent` | An agent |
+| `event`, `command`, `query` | A message of that kind |
+| `message` | An event, command or query with that id |
+| `channel` | A channel |
+| `data-store` (or `container`) | A data store |
+| `flow` | A flow |
+| `entity` | An entity |
+| `team`, `user` | A team or a user |
+
+`version` is an exact version or a semver range. Only the latest version of each resource is exported, so it must match the latest one.
+
+### By custom property
+
+Every resource with [custom properties](/docs/development/customization/custom-properties) that have the given values:
+
+```yaml
+- x-operational-tier: [1, 2]
+  kind: [service, agent]
+```
+
+| Key | Description |
+| --- | --- |
+| `x-…` | A custom property, and the value (or list of values) it must have. Every `x-` key in a selector must match. |
+| `kind` | Optional. One kind, or a list of them, from the table above. |
+
+- Values are compared as text: `true` matches `true` and `"true"`, and `1` matches `1` and `"1"`.
+- A resource's list matches when any of its items does.
+- Objects can't be matched.
+- A selector can't also name a resource by id, or take a `version`.
+
+## Configuration {#configuration}
+
+### `exports.html` {#exports-html}
+
+<AddedIn version="5.1.0" />
+
+| Option | Type | Default | Description |
+| --- | --- | --- | --- |
+| `exports.html.enabled` | `boolean` | `true` (`false` with authentication) | Write the architecture reference when you build. |
+
+### `exports.custom` {#exports-custom}
+
+<AddedIn version="5.2.0" />
+
+| Option | Type | Default | Description |
+| --- | --- | --- | --- |
+| `exports.custom.enabled` | `boolean` | `true` (`false` with authentication) | Write the custom exports when you build. |
+| `exports.custom.dir` | `string` | `'exports'` | The folder with your custom export files, relative to your catalog. |
+| `exports.custom.only` | `string[]` | | Build only these custom exports, by id. The CLI can still export any of them. |
+| `exports.custom.defaults.hide` | `string[]` | `['owners', 'repository', 'contacts', 'docs']` | What every custom export [hides](#hide), unless it sets its own `hide`. |
+| `exports.custom.defaults.references` | `string` | `'omit'` | What every custom export shows for [links out of it](#references), unless it sets its own. |
+| `exports.custom.neverExport` | `object[]` | | [Selectors](#selectors) for resources no custom export may show, whatever it includes. |
+
+### When exports are written
+
+| Your catalog | `enabled` not set | `true` | `false` |
+| --- | --- | --- | --- |
+| Without [authentication](/docs/development/authentication/introduction) | Written | Written | Not written |
+| With authentication | Not written | Written | Not written |
+
+Files in the build output are served without the authentication checks, so catalogs with authentication must turn exports on. Custom exports are only looked for when the folder has `.md` or `.mdx` files.
+
+Each custom export is written on its own. One with a problem (a field that isn't valid, an id another file uses too, or nothing in it) is skipped with a warning in the build's output, and the others are still written. The build doesn't fail.
+
+### Example
+
+```js title="eventcatalog.config.js"
+module.exports = {
+  exports: {
+    html: {
+      enabled: true,
+    },
+    custom: {
+      only: ['partner-payments', 'personal-data'],
+      defaults: {
+        hide: ['owners', 'repository', 'contacts', 'docs'],
+        references: 'omit',
+      },
+      neverExport: [
+        { service: 'fraud-detection' },
+        { 'x-data-classification': ['confidential', 'restricted'] },
+      ],
+    },
+  },
+};
+```
+
+See the [full configuration reference](/docs/api/config) for every EventCatalog option.
+
+## CLI {#cli}
+
+Run the [`export` command](/docs/cli/cli-export) of the [EventCatalog CLI](/docs/cli) from the root of your catalog:
+
+```bash
+# The architecture reference
+npx @eventcatalog/cli export --format html
+
+# A custom export, by id
+npx @eventcatalog/cli export partner-payments
+
+# What's in a custom export, without writing it
+npx @eventcatalog/cli export partner-payments --check
+```
+
+| Option | Description |
+| --- | --- |
+| `<id>` | The custom export to write. Leave it out, with `--format html`, for the architecture reference. |
+| `--format html` | Export as HTML. Not needed with an id. |
+| `--check` | With an id: list what's in the export, what was left out and why, without writing it. |
+| `--output <path>` | Where to write the file. Defaults to `architecture.html` or `<id>.html` |
+| `--no-open` | Don't open the file in your browser. It's never opened in CI, or when the output isn't a terminal. |
+| `--stdout` | Print the HTML instead of writing a file. |
+| `--dir <path>` | Path to your catalog, if you aren't running the command from it. |
+
+The command exits with `1` when an export has a problem (an unknown id, or a field that isn't valid), and when `--check` finds a selector that matches nothing in the catalog.
+
+### Check output
+
+`--check` lists, in groups:
+
+| Group | What it lists |
+| --- | --- |
+| Included | Every resource in the export, and why: `include`, `in system …`, `include x-public: true`, `referenced by …` |
+| Excluded | What `exclude` or `neverExport` took out of what the export would otherwise have |
+| Links dropped | Links to resources outside the export, and why: `not in this export`, `exclude` |
+| Links shown as names | With `references: name-only`, the links shown as plain names |
+| Not found | Selectors that matched nothing, and why |
+| Links in docs that lead outside the export | `[[type\|id]]` links in docs, and the text shown in their place |
+| Hidden | The fields left out |
+
+## SDK {#sdk}
+
+[`getResourcesByProperty`](/docs/development/customization/custom-properties#find-resources-by-custom-property) finds resources by custom property, as custom exports do:
+
+```js
+import utils from '@eventcatalog/sdk';
+
+const { getResourcesByProperty } = utils('/path/to/eventcatalog');
+
+await getResourcesByProperty('x-operational-tier', { equals: 1, types: ['service'], latestOnly: true });
+```
+
+| Option | Type | Description |
+| --- | --- | --- |
+| `equals` | any | Only resources whose value is this one. |
+| `in` | `array` | Only resources whose value is one of these. |
+| `types` | `string[]` | Only these kinds of resource, such as `service`, `event` or `domain`. |
+| `latestOnly` | `boolean` | Only the latest version of each resource. |
+
+Each result has the resource's `type`, `id`, `version`, the property's `value`, the `path` to its file and whether it's the `latest` version.
+
+## Exporters package {#exporters-package}
+
+To export from your own scripts, use the `@eventcatalog/exporters` package, which the build and the CLI use:
+
+```js
+import { renderHtml, writeHtml, renderCustomExports, writeCustomExports, formatCustomExportReport } from '@eventcatalog/exporters';
+
+// The architecture reference
+const { html } = await renderHtml('/path/to/catalog');
+await writeHtml({ dir: '/path/to/catalog', outputPath: 'architecture.html' });
+
+// Custom exports: all of them, or those in `only`
+const { rendered, failed } = await renderCustomExports('/path/to/catalog', { only: ['partner-payments'] });
+console.log(formatCustomExportReport(rendered[0].report));
+await writeCustomExports({ dir: '/path/to/catalog', outputDir: 'dist/exports' });
+```
+
+| Function | Returns |
+| --- | --- |
+| `renderHtml(dir)` | `{ html, model }`: the architecture reference |
+| `writeHtml({ dir, outputPath })` | `{ html, model, path, bytes, durationMs }` |
+| `renderCustomExports(dir, { only?, config? })` | `{ rendered, failed }`: `rendered` has `{ spec, html, model, report }` for each custom export, and `failed` has `{ id, file, error }` for each one that couldn't be exported |
+| `writeCustomExports({ dir, outputDir, only?, config? })` | `{ written, failed }`: the same, with each file's `path` and `bytes` |
+| `formatCustomExportReport(report)` | The `--check` output, as text |
+| `loadCatalog(dir)` | The catalog as one resolved model, to build your own export |
+
+`config` is `exports.custom` from `eventcatalog.config.js`, which is read from the catalog when you don't pass it.
+
+Each custom export stands alone. One that can't be exported (its file has problems, two files share its id, it has nothing in it, or an id in `only` has no file) is in `failed`, with a `CustomExportError` that lists every problem in its `problems`, and the others are still exported. A problem with `exports.custom` itself throws.

package/dist/docs/development/export/_category_.json

@@ -0,0 +1,12 @@
+{
+  "label": "Export your catalog",
+  "position": 4.4,
+  "collapsible": true,
+  "collapsed": false,
+  "link": {
+    "type": "generated-index",
+    "slug": "development/export",
+    "title": "Export your catalog",
+    "description": "Share your architecture with people who can't open your catalog: all of it, or just the part they need, as one HTML file."
+  }
+}

package/dist/docs/development/guides/owners/05-teams-reference.md

@@ -78,18 +78,6 @@ email: payments@example.com
 ---
 ```
 
-### `hidden` {#hidden}
-
-- Type: `boolean`
-
-Hide the team from generated lists.
-
-```md title="Example"
----
-hidden: true
----
-```
-
 ### `slackDirectMessageUrl` {#slackDirectMessageUrl}
 
 - Type: `string`

package/dist/docs/development/guides/owners/06-users-reference.md

@@ -90,18 +90,6 @@ email: david@example.com
 ---
 ```
 
-### `hidden` {#hidden}
-
-- Type: `boolean`
-
-Hide the user from generated lists.
-
-```md title="Example"
----
-hidden: true
----
-```
-
 ### `slackDirectMessageUrl` {#slackDirectMessageUrl}
 
 - Type: `string`