0.8.0

Breaking Changes

Code Generation Changes

• Non-200 success status codes now generate explicit status_code parameter - Endpoints whose OpenAPI spec defines only non-200 success responses (e.g., 201, 202) now include status_code=201 (or 202, etc.) in the generated route decorator. Previously, only 204 no-content responses received an explicit status_code. This changes the generated output for any spec with 201, 202, or other 2xx-only responses, which will cause diffs when regenerating code. (#610)
• Primary non-200 success response now uses response_model instead of responses dict - When an endpoint's only success response is a non-200 code (e.g., 201) with a response body schema, the generated code now uses response_model=<Model> and status_code=201 instead of the previous response_model=None, responses={'201': {'model': Model}}. For example:

  # Before
  @app.post('/subscriptions', response_model=None, responses={'201': {'model': Subscription}})
  def create_subscription(body: SubscriptionRequest) -> Optional[Subscription]:
  # After
  @app.post('/subscriptions', response_model=Subscription, status_code=201)
  def create_subscription(body: SubscriptionRequest) -> Subscription:

  This also changes the return type annotation from Optional[Model] or Optional[Union[...]] to Model or Union[...] (removing the Optional wrapper). Any code depending on the previously generated signatures, response handling, or Optional return types will need updating. (#610)
• Non-200 success responses now use response_model and status_code instead of responses dict - Previously, endpoints with non-200 success status codes (e.g., 201) generated response_model=None with the model placed in the responses={'201': {'model': Model}} dict. Now, the primary success response is promoted to response_model=Model with an explicit status_code=201. This changes the actual HTTP status codes returned by generated FastAPI applications (previously defaulted to 200, now returns the correct status code). Return type annotations also change from Optional[Model] to Model. Existing generated code that relies on the old responses dict structure or 200 status codes will behave differently after regeneration. (#611)
  Before:

  @app.post('/subscriptions', response_model=None, responses={'201': {'model': Subscription}})
  def create_subscription(body: SubscriptionRequest) -> Optional[Subscription]:

  After:

  @app.post('/subscriptions', response_model=Subscription, status_code=201)
  def create_subscription(body: SubscriptionRequest) -> Subscription:

• Endpoints with non-200 success codes now emit explicit status_code in decorators - Operations that define only a 201 (or other non-200) success response without a response body now generate status_code=201 in the route decorator. Previously, no status_code was emitted and FastAPI would default to 200. This affects POST, PUT, and other write endpoints across all templates (default and router). (#611)
  Before:

  @app.post('/pets', response_model=None, tags=['pets'])

  After:

  @app.post('/pets', response_model=None, status_code=201, tags=['pets'])

Custom Template Update Required

• operation.status_code is now populated for more endpoints - Custom Jinja2 templates that reference operation.status_code will now receive non-None values for endpoints with non-200 success status codes (e.g., 201, 202), not just 204. Templates that already handle status_code (like the built-in templates) will work correctly, but custom templates that assumed status_code was only set for 204 may need review. (#610)
• operation.response and operation.additional_responses may differ - For specs where the primary success response is non-200, operation.response now contains the actual model type (e.g., Subscription) instead of None, and the primary status code entry is removed from operation.additional_responses. Custom templates referencing these fields may produce different output. (#610)
• operation.status_code is now set for all non-200 success status codes - Previously, operation.status_code was only populated for 204 no-content responses. It is now set for any non-200 success status code (201, 202, etc.). Custom Jinja2 templates that use {% if operation.status_code %} will now render status_code= for many more routes than before. Additionally, operation.response now contains the actual model name (e.g., 'Subscription') instead of 'None' for non-200 success responses, and operation.additional_responses no longer includes the primary success response entry. (#611)

Python or Dependency Support Changes

• Minimum datamodel-code-generator version raised from 0.59 to 0.61 - The dependency constraint changed from >=0.59,<0.60 to >=0.61,<0.66. Users pinned to datamodel-code-generator 0.59 or 0.60 must upgrade to at least 0.61. (#611)

What's Changed

• Fix 201 response generation by @koxudaxi in #610
• Update datamodel-code-generator requirement by @koxudaxi in #611

Full Changelog: 0.7.0...0.8.0

0.7.0

Breaking Changes

Code Generation Changes

• Shadowed imports no longer use aliases - Generated code that previously aliased conflicting imports (e.g., from datetime import date as date_aliased) now uses the direct type reference (e.g., from datetime import date). Function signatures also change accordingly (e.g., date_aliased → date). Users who regenerate code may see different output, and downstream code referencing aliased names will need updating. (#589)
• 204 no-content endpoints now include explicit status_code=204 - Previously, endpoints with only a 204 response in the OpenAPI spec generated without a status_code parameter (defaulting to HTTP 200 at runtime). Now the generated code includes status_code=204 in the route decorator. Users who regenerate code from specs containing 204 responses will see different output and may need to update snapshots or tests that compare generated code. (#601)
• Removed automatic status_code=204 from generated route decorators - Previously, when an endpoint had a 204 response (with no 200 response), the generated code included status_code=204 in the @app.post(...) decorator. This parameter is no longer emitted, changing generated output for any spec using 204 No Content responses. (#595)
• Header and cookie parameters now use FastAPI dependency injection - Parameters with in: header or in: cookie in OpenAPI specs are now generated with Header(...) and Cookie(...) wrappers instead of plain function parameters. Regenerating code from specs that include header or cookie parameters will produce different output. For example, a header parameter trace_id previously generated as trace_id: str will now generate as trace_id: str = Header(..., alias='trace_id'). This also adds new from fastapi import Header, Cookie imports to generated files. (#602)
• Non-200 success status codes now included in route decorators - Operations whose only success response is a non-200 code (e.g., 204 No Content) now generate status_code=204 in the @app.get(...) decorator. Previously this was omitted. Regenerated code for such endpoints will differ. (#602)
• Vendor extensions filtered from info block - Keys starting with x- in the OpenAPI info object are now stripped from the generated FastAPI() constructor arguments. Previously these were passed through, which could cause runtime errors in FastAPI. (#602)

Python or Dependency Support Changes

• datamodel-code-generator minimum version raised from 0.56.1 to 0.59 - The required version of datamodel-code-generator[http] changed from >=0.56.1,<0.57 to >=0.59,<0.60, dropping support for versions 0.56.x through 0.58.x. Users pinned to older versions of datamodel-code-generator will need to upgrade. (#589)

Custom Template Update Required

• New operation.status_code field available in templates - A new status_code attribute (Optional[int]) has been added to the Operation model passed to Jinja2 templates. Users with custom templates who want correct 204 handling should add the following block after response_model={{operation.response}}:

    {% if operation.status_code %}
    , status_code={{operation.status_code}}
    {% endif %}

Existing custom templates will continue to work without this addition but will not emit the status_code parameter for no-content endpoints. (#601)

• Removed operation.status_code field from the Operation model - Custom Jinja2 templates referencing operation.status_code (e.g., {% if operation.status_code %}, status_code={{operation.status_code}}{% endif %}) must remove those references, as the field no longer exists on the Operation class. (#595)
• Default templates now include status_code conditional - The built-in main.jinja2 and routers.jinja2 templates now emit status_code={{operation.status_code}} when set. Users with custom copies of these templates should add the following block after the response_model= line to get equivalent behavior:

  {% if operation.status_code %}
      , status_code={{operation.status_code}}
  {% endif %}

  Custom templates that do not add this block will still work but will not emit status codes for 204 endpoints. (#602)

What's Changed

• Fix release followup workflows by @koxudaxi in #576
• Backfill changelog from releases by @koxudaxi in #577
• Support datamodel-code-generator 0.59 by @koxudaxi in #589
• Fix root endpoint path generation by @koxudaxi in #590
• Add OpenAI OpenAPI regression coverage by @koxudaxi in #592
• Fix union body imports by @koxudaxi in #597
• Add router tag sort regression coverage by @koxudaxi in #593
• Add invalid parameter name regression coverage by @koxudaxi in #591
• Add Python 3.10 install smoke test by @koxudaxi in #599
• Fix router tag template rendering by @koxudaxi in #598
• Fix no-content status code generation by @koxudaxi in #601
• Add Field examples regression coverage by @koxudaxi in #594
• Fix vendor extension info fields by @koxudaxi in #600
• Add missing request schema regression coverage by @koxudaxi in #595
• Add formatter pyproject regression coverage by @koxudaxi in #596
• Fix header and cookie parameter generation by @koxudaxi in #602

Full Changelog: 0.6.0...0.7.0

0.6.0

Breaking Changes

Python or Dependency Support Changes

• Dropped Python 3.9 runtime support - Package metadata now requires Python 3.10 or newer, removes the Python 3.9 classifier, and updates the supported runtime range to Python 3.10 through 3.14 (#514)
• Dropped Python 3.9 target generation - The CLI --python-version choices no longer include 3.9, so users generating Python 3.9-compatible output need to stay on an older release or target Python 3.10+ (#534)

API/CLI Changes

• Removed the Pydantic v1 BaseModel output option - --output-model-type no longer exposes pydantic.BaseModel, and scripts that pass that value need to switch to a supported output backend (#534)

Default Behavior Changes

• Changed the default model backend to Pydantic v2 - --output-model-type now defaults to pydantic_v2.BaseModel, which changes generated model imports and configuration unless users explicitly choose another backend (#534)

Code Generation Changes

• Changed generated FastAPI parameter and model output - Optional query parameters may now use explicit Query(...) defaults or aliases, and generated models move from Pydantic v1 patterns to Pydantic v2-style configuration (#534)

What's Changed

• remove typed-ast (EOL) from dependencies and update poetry.lock by @marcoemorais in #483
• Bump pytest-cov from 5.0.0 to 7.1.0 by @dependabot[bot] in #502
• chore: migrate to uv and support Python 3.10-3.14 by @koxudaxi in #514
• Add CLI E2E coverage pipeline by @koxudaxi in #516
• Port workflow and docs automation stack by @koxudaxi in #517
• Update hatchling requirement from >=1.27 to >=1.29.0 by @dependabot[bot] in #528
• Align CI/CD hardening workflows by @koxudaxi in #538
• Align CI workflows with datamodel-code-generator by @koxudaxi in #539
• Harden generated docs CI checks by @koxudaxi in #551
• Update datamodel-code-generator to 0.56.1 by @koxudaxi in #534
• fix: Allow hyphen in tags by @koxudaxi in #552
• fix: Allow hyphen in tags by @tobias-bahls in #497
• Fix a versioning issue with click by @relaxbox in #498
• Support for use-annotated by @jnu in #518
• Fix PR 518 followups by @koxudaxi in #555
• Preserve router path parameter names by @koxudaxi in #554
• Expose plain arguments by @LuisHsu in #454
• Fix multiple file upload generation by @koxudaxi in #553
• Add support for setting strict_nullable from CLI by @greg80303 in #493
• Fix specify-tags router filtering by @koxudaxi in #558
• Fix stringcase dependency with setuptools 78.0.0 by @koxudaxi in #565
• Add faux immutability option by @koxudaxi in #569
• Fix discriminated union simple types by @koxudaxi in #566
• Expose reuse model option by @koxudaxi in #568
• Preserve query array parameter types by @koxudaxi in #567
• Restore release draft analysis by @koxudaxi in #571
• Fix release draft gh repository context by @koxudaxi in #572
• Fix release draft label permissions by @koxudaxi in #573
• Use REST API for release draft labels by @koxudaxi in #574
• Fix release draft PR label scope by @koxudaxi in #575

New Contributors

• @marcoemorais made their first contribution in #483
• @tobias-bahls made their first contribution in #497
• @relaxbox made their first contribution in #498
• @LuisHsu made their first contribution in #454
• @greg80303 made their first contribution in #493

Full Changelog: 0.5.4...0.6.0

0.5.4

What's Changed

• Remove deprecated datamodel-code-generator patch by @sternakt in #489
• Bump version by @sternakt in #490

Full Changelog: 0.5.3...0.5.4

0.5.3

What's Changed

• Improve code generation with fixes for recursion, aliasing, and modular references by @sternakt in #484
• Fix docs build in CI by @davorrunje in #485
• Fix publish in CI by @davorrunje in #486

New Contributors

• @sternakt made their first contribution in #484

Full Changelog: 0.5.2...0.5.3

0.5.3rc0

What's Changed

• Improve code generation with fixes for recursion, aliasing, and modular references by @sternakt in #484
• Fix docs build in CI by @davorrunje in #485
• Fix publish in CI by @davorrunje in #486

New Contributors

• @sternakt made their first contribution in #484

Full Changelog: 0.5.2...0.5.3rc0

0.5.2

What's Changed

• Fix target_python_version by @chantera in #445
• Fix parameter field name by @chantera in #446
• Add --model-template-dir option by @chantera in #447

New Contributors

• @chantera made their first contribution in #445

Full Changelog: 0.5.1...0.5.2

0.5.1

What's Changed

• Update typer by @davorrunje in #430
• Support for Pydantic 2 & additional python versions by @jnu in #414
• Fix generate_code args by @koxudaxi in #436
• fix inconsistance routers<>tags arrays by @azdolinski in #417
• 419 / Support for parsing callbacks by @jnu in #420

New Contributors

• @davorrunje made their first contribution in #430
• @jnu made their first contribution in #414
• @azdolinski made their first contribution in #417

Full Changelog: 0.5.0...0.5.1

0.5.0

What's Changed

• Update pydantic to v2 and update datamodel-code-generator to 0.25.6 by @kumaranvpl in #408

New Contributors

• @kumaranvpl made their first contribution in #408

Full Changelog: 0.4.4...0.5.0

0.4.4

What's Changed

• Generate correct python code if path is camel case by @yyamano in #380
• Generate valid python code if query param exists and requeststBody is required by @yyamano in #382
• Allow modular output with custom templates by @notpushkin in #384
• Fixed broken test (Added option for inputting encoding of file #334) by @yyamano in #383

New Contributors

• @notpushkin made their first contribution in #384

Full Changelog: 0.4.3...0.4.4