- FastAPI 0.151.0 now treats a JSON null differently from a field that is left out of a request body.
- Clients that sent null to get a default value may now receive validation errors, so the upgrade needs testing.
- Teams should check which clients send null, then fix them to omit the field before upgrading.
A blank field and a field marked N/A are not the same thing
Anyone who has filled in a paper form knows the difference. Leaving a box empty says nothing. Writing "N/A" says something specific. Software APIs have the same two choices, and FastAPI 0.151.0 now treats them as different.
The release, published October 20, 2026, changes how FastAPI reads JSON request bodies. A field can be omitted, or it can be sent with the explicit value null. The release notes say the framework now distinguishes the two.
The idea for leaders is simple. A small change in how a service reads its inputs is a change to the contract with every client. Those clients may belong to other teams, partners or customers.
What the release changes
Under the new behavior, an explicit null in a body parameter is validated as None, the empty value. The release notes give the rules.
If the parameter's type allows null, the request is accepted. If it does not, the request is rejected, even when the parameter has a default. Defaults, and default factories that build a default, apply only when the value is omitted.
The same applies to parameters inside a JSON object and to a parameter that represents the whole body. There is one more case. When the API expects a JSON object, because of Body(embed=True) or several body parameters, a body of null now returns a validation error.
The project lists the change as a bug fix, in pull request #16536 by @tiangolo. The notes do not say how many applications are affected.
Where existing clients could break
The release notes give one instruction to client developers: those who used null to request a default should omit the value instead. That advice suggests some clients relied on null meaning "use the default". That inference is ours. The notes do not say how common the habit is.
Consider a mobile app or partner integration that sends every field on every call. Where it has nothing to say, it sends null. After the upgrade, a field that is not nullable and receives null is rejected. This happens even if the server defines a default for it.
The failure would show up as validation errors on requests that worked before. The service itself would be running normally. The person who notices is likely to be a customer or a partner, not the engineer who upgraded.
Why this is a contract question, not a coding detail
Stricter input handling is generally the kind of change teams want. It removes ambiguity about what a client meant. A null that silently turns into a default can hide a client mistake.
The cost is in the transition. The people who bear it are those who cannot change their clients quickly. Examples include apps already installed on phones, integrations run by partners, and older internal tools. Whether any of those exist is something only your own team can tell you.
The release notes describe the new rules and the fix for clients. They do not describe a way to find which clients are sending null today. That job falls to the team running the service.
What to ask your team
Before FastAPI services move to 0.151.0, put four questions to the owners.
First, do any of our clients send explicit null for fields that have server-side defaults? Request logs from a test environment can answer this.
Second, which fields are declared as not accepting null? Those are the ones that will now reject it.
Third, are there endpoints that accept a whole-body null, or that use Body(embed=True)? Those now return a validation error for that input.
Fourth, who owns each client, and how fast can they change? If the answer is "not quickly", plan the upgrade around that.
A new rule about empty values sounds minor. In practice, it decides whether a client's request is still accepted. Treat it as a change to your API's contract, and test it with that in mind.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub (fastapi/fastapi).
