FastAPI has published 0.156.6, a small bug-fix release that corrects how parameter models handle alias configuration. The change targets a subtle but important mismatch: when a Pydantic model defines field aliases and that model is used to declare Query, Header, or Cookie parameters, FastAPI now honors those alias settings instead of ignoring them.
According to the release notes, the fix comes in a single pull request from the maintainer:
- Respect model alias settings for
Query,Header, andCookieparameters, so aliased fields in a parameter model are resolved consistently with the model's own configuration. - The fix ships via PR #16562, authored by @tiangolo.
The practical effect is consistency between the model layer and the request layer. Pydantic models commonly use aliases for fields that do not match the external wire name — for example, a camelCase field that maps to a snake_case attribute, or a public name that differs from an internal one. Before this patch, parameters documented through such models could disagree with the model's declared aliases for query strings, headers, and cookies, leading to requests that validated in one place but not another.
For developers, this matters most in codebases that lean on parameter models to keep endpoint signatures tidy, particularly APIs with many query or header arguments. If you have worked around the old behavior with explicit alias= arguments on individual parameters, it is worth re-testing those endpoints after upgrading. The tighter alignment between model configuration and request parsing also reduces the chance of documentation drift, since generated OpenAPI schemas can now follow the same alias definitions used at runtime. The release contains no other listed changes, making it a low-risk upgrade focused on correctness.
Source: https://github.com/fastapi/fastapi/releases/tag/0.156.6