fastapi-pydantic-boundaries

Create distinct input models for accepted fields and output models for public response fields, using separate create, update, and read models when optionality or exposure differs. Never return ORM or internal objects and assume response filtering will protect secrets.

A ValidationError raised inside application logic is not automatically a client request error; translate it only at the boundary that understands it. Response-model validation failure is a server defect and should surface as a server error, not a relabeled 422.

Aliases must be decided explicitly as part of the HTTP contract, distinguishing input aliases from serialized output names. Do not rely on a parameter rename to preserve external names; inspect the generated OpenAPI to confirm actual behavior.

Annotated dependencies and fields can combine metadata in non-obvious ways, so precedence cannot be guessed. Inspect the generated OpenAPI schema directly and test requests through the ASGI test client to confirm the real contract.

It does not apply to standalone FastAPI routing with no model interaction or standalone Pydantic models with no ASGI boundary. It targets only the intersection where HTTP request, dependency, response, or OpenAPI behavior meets Pydantic v2 validation.