fastapi-pydantic-boundaries

Name: fastapi-pydantic-boundaries
Availability: InStock
Author: schattenspiegel

Defines FastAPI request and response contracts using Pydantic v2 validation and serialization.

Updated Aug 12, 2026

Search Tags:#pydantic #fastapi #api design #python #openapi #validation #serialization

Ready to run

npx skills add https://github.com/schattenspiegel/skill-foundry-skills --skill fastapi-pydantic-boundaries-schattenspiegel

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: fastapi-pydantic-boundaries
Source: https://github.com/schattenspiegel/skill-foundry-skills/tree/main/skills/fastapi-pydantic-boundaries
Command: npx skills add https://github.com/schattenspiegel/skill-foundry-skills --skill fastapi-pydantic-boundaries-schattenspiegel

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? FastAPI endpoints often blur the line between HTTP wire contracts and internal domain or ORM objects, causing leaked secrets, broken aliases, mislabeled validation errors, and OpenAPI schemas that do not match actual behavior. This Skill provides a structured workflow for keeping the HTTP boundary explicit and correct. ## Core Features & Use Cases - Explicit parameter sourcing: Declare path, query, header, cookie, and body sources directly instead of relying on parameter renames. - Input/output model separation: Use distinct create, update, and read models so optionality and field exposure stay under control. - Error boundary discipline: Translate domain failures into documented HTTP errors while keeping response-validation defects as server errors, never relabeled 422s. - Use Case: When building an endpoint that accepts a discriminated-union payload with aliased fields, use this Skill to define the wire contract, verify the generated OpenAPI, and test malformed inputs through the ASGI test client. ## Quick Start Ask the assistant to review my FastAPI endpoint's request and response models and verify the Pydantic v2 validation, aliases, and OpenAPI contract.

Frequently Asked Questions about fastapi-pydantic-boundaries

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I separate request and response models in FastAPI with Pydantic v2?▼

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.

How do I handle Pydantic ValidationError in FastAPI endpoints?▼

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.

Does FastAPI preserve field aliases in requests and responses?▼

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.

Why does my FastAPI OpenAPI schema not match actual validation 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.

When should I not use this FastAPI-Pydantic boundary approach?▼

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.