litestar-openapi
OpenAPI
Execution Workflow
- Decide whether OpenAPI should be enabled, restricted, or disabled for the app.
- Set app-level
OpenAPIConfigfor title, version, docs endpoints, servers, tags, and render plugins. - Add route-level metadata deliberately:
summary,description,response_description,tags,security,operation_id,raises, andinclude_in_schema. - Use schema-generation customization only when default model generation is insufficient.
- Choose UI render plugins and endpoint paths intentionally for each environment.
- Validate that generated docs match real request, auth, and metrics behavior.
Core Rules
- Keep documentation truthful to runtime behavior.
- Centralize OpenAPI config at app construction.
- Use route-level metadata only where it improves clarity or correctness.
- Disable schema generation with
openapi_config=Noneonly when docs must not be exposed. - Keep request, response, security, and metrics documentation aligned with the skills that own those runtime behaviors.
- Prefer current render-plugin configuration over legacy controller-style customization paths.
- Treat OpenAPI changes as API changes that require review.
Decision Guide
- Use app-level
OpenAPIConfigfor global schema and docs endpoint strategy. - Use route-level metadata when one operation differs from the app default.
- Use
operation_classor schema customization only when built-in generation is insufficient. - Use
include_in_schema=Falsefor internal or operational routes that should stay out of public docs. - Use UI plugins when interactive docs are required; choose the plugin based on audience and deployment constraints.
- Use one of the bundled render plugins rather than hand-building docs pages unless the UI must be bespoke.
Reference Files
Read only the sections you need:
- For schema generation, enabling/disabling docs, route-level metadata, and operation customization, read references/schema-and-operations.md.
- For UI render plugins, docs endpoints, path customization, and offline/CDN considerations, read references/ui-plugins-and-endpoints.md.
Recommended Defaults
- Keep app title, version, and server metadata explicit.
- Use route-level descriptions and summaries sparingly but intentionally.
- Document security requirements where auth actually applies.
- Keep internal or noisy operational endpoints out of the public schema when appropriate.
- Prefer a single clear docs UI per environment unless multiple UIs solve a real need.
Anti-Patterns
- Documenting contracts that runtime behavior does not actually support.
- Leaving stale examples, tags, or security docs after runtime changes.
- Overusing route-level overrides until the schema becomes inconsistent.
- Exposing internal routes in the schema without intent.
- Treating UI plugin choice as purely cosmetic when endpoint paths and asset loading matter operationally.
- Customizing schema generation before understanding the default output.
Validation Checklist
- Confirm schema generation is enabled or disabled intentionally.
- Confirm public routes appear in the schema and internal-only routes are omitted where intended.
- Confirm request, response, auth, and metrics surfaces are documented consistently with runtime behavior.
- Confirm operation IDs, tags, and summaries are stable and useful.
- Confirm documented exceptions and security requirements match the real route behavior.
- Confirm chosen UI plugin paths and asset sources are correct for the deployment environment.
- Confirm generated JSON and YAML schema endpoints behave as expected.
Cross-Skill Handoffs
- Use
litestar-requests,litestar-responses, andlitestar-dtowhen schema mismatches originate in transport modeling. - Use
litestar-authenticationandlitestar-securitywhen security scheme docs must match auth backends and guard behavior. - Use
litestar-metricswhen operational endpoints or metrics docs should be included or excluded intentionally. - Use
litestar-testingwhen schema and docs stability need regression coverage.
Litestar References
More from alti3/litestar-skills
litestar-responses
Build Litestar responses with typed return values, explicit Response containers, layered response classes, headers, cookies, status-code control, redirects, files, streams, server-sent events, ASGI app returns, and background tasks. Use when shaping outbound HTTP behavior, correcting response contracts, or choosing the right Litestar response primitive. Do not use for request parsing, validation, or authentication policy design.
22litestar-logging
Configure Litestar logging with `LoggingConfig`, `queue_listener`, exception logging policy, selective stack-trace suppression, standard logging, picologging, Structlog, and custom logging config subclasses. Use when establishing or refactoring application logging behavior, request-level logs, or production-safe error logging in Litestar. Do not use for metrics/tracing instrumentation or exception-response contract design.
22litestar-authentication
Implement Litestar authentication with custom authentication middleware, built-in security backends, JWT and session flows, route inclusion and exclusion rules, and typed auth context on `Request` / `ASGIConnection`. Use when establishing identity, issuing or validating credentials, or attaching authenticated user context in Litestar. Do not use for generic request parsing, broad security audits, or unrelated transport concerns.
22litestar-middleware
Design and apply Litestar middleware for cross-cutting concerns such as CORS, CSRF, allowed-host checks, compression, rate limiting, logging, sessions, request enrichment, policy enforcement, and custom ASGI pipeline control. Use when behavior must wrap broad route sets consistently across the ASGI stack. Do not use for route-specific business rules, simple response mutation better handled by lifecycle hooks, or auth/guard policy work that belongs in security-focused skills.
20litestar-routing
Design and implement Litestar routing with app/router/controller composition, handler decorators, path and parameter modeling, route indexing/reverse lookups, ASGI mounting, and layered route metadata. Use when creating or refactoring endpoint topology and URL contracts. Do not use for purely internal service logic unrelated to HTTP route structure.
18litestar-dto
Configure Litestar DTO behavior for inbound parsing and outbound serialization, including layer-scoped `dto`/`return_dto`, `DTOConfig` policies, `DTOData` update workflows, and custom `AbstractDTO` implementations. Use when API payload contracts differ from internal model structures. Do not use when internal models can be exposed safely without transformation.
18