Skip to main content
Any custom Payload endpoint that carries custom.openapi metadata is picked up automatically. The metadata is a standard OpenAPI Operation Objectsummary, tags, parameters, requestBody, responses, and so on. Endpoints without it are skipped, so nothing internal leaks into the spec by accident.
payload.config.ts
This is the same custom.openapi convention that Payload’s own agent skills document. The plugin reads exactly that shape — no plugin-specific wrapper, no separate registry to keep in sync. Endpoints already documented this way show up with zero changes.

Where endpoints are collected from

The plugin walks every endpoint list in the sanitized config: The /api segment follows your routes.api setting. Path params written Express-style (:id) are normalized to OpenAPI placeholders ({id}), so a collection endpoint at /:id/tracking on posts is documented as /api/posts/{id}/tracking.
Custom endpoints are documented only while filters.includeCustom stays on. It defaults to true; turning it off drops every custom.openapi endpoint from the spec. See Filters.

Examples

Request body

collections/Posts.ts

Path parameters

Declare params under parameters exactly as in any OpenAPI operation. The :id in the Payload path and the {id} in the parameter refer to the same thing:
collections/Posts.ts

Tags

Tags group operations in the docs UI. Reuse an existing entity tag to file the operation alongside the generated CRUD routes, or introduce your own:
globals/Settings.ts
description and summary in the operation object are localizable — pass a translation function or a locale-keyed object and they resolve against the request language. See Field metadata for the shape and i18n for the language plumbing.

Filters

Control which entities and operations end up in the spec, including includeCustom.

For plugin authors

Ship documented endpoints from your own plugin with no dependency on this package.