FastAPI 0.151.0 has landed with a breaking change to how JSON request bodies are validated. As of this release, an explicit null is no longer treated the same as an omitted value. The change was authored by @tiangolo in PR #16536 and affects both individual Body parameters and parameters representing the entire body.
The practical consequence is that null is now validated as None rather than silently falling back to a default. Nullable types accept it; non-nullable types reject it, even when a default is defined. Defaults and default factories apply only when the value is omitted entirely.
- Explicit
nullvs. omitted values are now distinguished for JSON request bodies. - For individual
Bodyparameters,nullis validated asNone: nullable types accept it, non-nullable types reject it even with a default defined. - Defaults and default factories apply only when the value is omitted, not when it is
null. - The behavior covers parameters inside JSON objects and parameters representing the entire body.
- When a JSON object is expected via
Body(embed=True)or multiple body parameters, sendingnullas the entire body now returns a validation error. - Clients that previously sent
nullto request a default value should omit the value instead.
For developers, this means auditing any client that relies on sending null to trigger defaults: such requests may now fail with a validation error depending on the parameter type. If your code or SDK sends null for a body-level parameter expecting an object, those requests will be rejected. The fix is generally simple — omit the field rather than sending null — but it should be verified before upgrading, since validation behavior shifts silently at the schema level. Teams with nullable body fields that intentionally accept null should confirm their types are declared as nullable so the new distinction does not break existing clients.
Source: https://github.com/fastapi/fastapi/releases/tag/0.151.0