Pydantic Field Validation

1. Adding Constraints with Field() and Annotated

In DRF, you'd add constraints directly as arguments to your serializer fields, like this:
name = serializers.CharField(max_length=50, min_length=3)

Pydantic has a very similar mechanism using the Field() function. In Pydantic v2, the modern and recommended way to apply these constraints is by using typing.Annotated. This approach keeps your type hints clean while "annotating" them with extra metadata that Pydantic uses for validation.

Let's see how to apply constraints for string length, numeric ranges, and even regular expression patterns.

As you saw, the pattern is straightforward. You wrap your original type with Annotated and pass a Field function with your desired constraints as the second argument.

Let's solidify this with a direct comparison to the DRF concepts you already know.

Here is a Pydantic model with several constraints:

from typing import Annotated
from pydantic import BaseModel, Field

class ItemCreate(BaseModel):
    name: Annotated[str, Field(min_length=3, max_length=50)]
    price: Annotated[float, Field(gt=0, description="The price must be a positive value.")]
    stock: Annotated[int, Field(ge=0)]  # Must be greater than or equal to 0
    sku: Annotated[str, Field(pattern=r'^[A-Z]{3}-\d{4}$')]  # e.g., 'ABC-1234'

And here's how those Pydantic constraints map to their DRF equivalents:

This powerful combination of Annotated and Field allows you to define most of your business logic for data validation declaratively, right in the schema.

2. Specialized Built-in Types

While Field() is flexible, Pydantic also provides convenient, pre-packaged types for very common validation scenarios. Using these can make your code even more readable and expressive. Think of these as shortcuts that bundle common constraints.

The most useful ones include:

• EmailStr: Validates that a string is a properly formatted email address.
• HttpUrl: Validates that a string is a valid HTTP or HTTPS URL.
• SecretStr: Used for sensitive data like passwords. It automatically redacts the value when the model is printed or logged, preventing accidental exposure.

Let's see them in practice.

These specialized types are another area where you can draw a direct line from your DRF experience.

• Pydantic's EmailStr is the direct equivalent of DRF's serializers.EmailField.
• Pydantic's HttpUrl is the direct equivalent of DRF's serializers.URLField.
• Pydantic's SecretStr provides similar protection to using write_only=True on a DRF serializer field, but with the added benefit of still being able to access the value in your application logic when needed.

Let's update our user model to use these more expressive types.

from pydantic import BaseModel, EmailStr, HttpUrl, SecretStr
from typing import Optional

class UserProfileUpdate(BaseModel):
    email: Optional[EmailStr] = None
    website: Optional[HttpUrl] = None
    password: Optional[SecretStr] = None # Will be hidden in logs

3. Putting It All Together

By combining standard types, the Annotated and Field pattern, and specialized Pydantic types, you can build very robust and descriptive validation schemas.

Here's a comprehensive example for creating a new user:

from pydantic import BaseModel, Field, EmailStr
from typing import Annotated

class UserCreate(BaseModel):
    username: Annotated[
        str,
        Field(
            min_length=3,
            max_length=20,
            pattern=r"^[a-zA-Z0-9_]+$",
            description="Username can only contain letters, numbers, and underscores."
        )
    ]
    email: EmailStr
    age: Annotated[int, Field(ge=18, le=120, description="User must be between 18 and 120 years old.")]
    password: Annotated[str, Field(min_length=8)]

This single class clearly and concisely defines a complex set of rules that FastAPI will automatically enforce on any incoming request to an endpoint that uses it. If any rule is violated, FastAPI will return a detailed 422 Unprocessable Entity error pointing to the exact problem.

For a final reference, the official Pydantic documentation provides a concise summary of these concepts.

Conclusion

You've now moved beyond basic type validation and can enforce precise business logic within your Pydantic models.

Key Takeaways:

• Field() is the primary tool for adding constraints like length, numeric ranges, and patterns to your model's fields.
• Annotated is the modern Pydantic v2 syntax for applying Field() constraints, keeping type hints clean and readable.
• The constraints provided by Field() have direct analogies in DRF, such as max_length, MinValueValidator, and RegexValidator.
• Pydantic offers specialized types like EmailStr and HttpUrl as convenient, readable shortcuts for common validation patterns, similar to EmailField and URLField in DRF.

So far, we've dealt with flat data structures. But real-world APIs often involve nested objects—for example, a blog post that contains a user object for the author.

In our next lesson, we will tackle this by learning how to create nested Pydantic models to represent complex, hierarchical JSON structures, a concept analogous to nested serializers in DRF.