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