Generate Pydantic Models for API Contracts

Pydantic Models creates Pydantic models following a multi-model pattern for clean API contracts, starting from a template (assets/template.py) with {{ResourceName}}/{{resource_name}} placeholders swapped for the actual PascalCase/snake_case resource name. The pattern splits a resource into five models: Base for fields shared across all variants, Create for the required-field request body on creation, Update with all fields optional for PATCH requests, Response carrying the full API response, and InDB adding a doc_type field for the database document.

Use it when defining a new API resource's data models with clean separation between creation, update, and response shapes rather than one overloaded model. For frontend compatibility, fields support camelCase aliases while keeping snake_case internally:

class MyModel(BaseModel):
    workspace_id: str = Field(..., alias="workspaceId")
    created_at: datetime = Field(..., alias="createdAt")
    
    class Config:
        populate_by_name = True  # Accept both snake_case and camelCase

Update models make every field optional for PATCH semantics (Optional[str] = Field(None, min_length=1)), and the database-document model extends the response model with a doc_type string constant (e.g. "my_resource") used for Cosmos DB queries.

Integration follows three steps: create the models in src/backend/app/models/, export them from src/backend/app/models/__init__.py, and add the corresponding TypeScript types on the frontend side to keep both sides of the API contract in sync.

Backend developers defining API resource models on a Pydantic/Cosmos DB stack who want a consistent Create/Update/Response/InDB split with camelCase-compatible field aliasing, rather than one general-purpose model reused across every request shape.