NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
PyPI · #2252 most downloaded on PyPI
Generate modern Python clients from OpenAPI
Last release 1 months ago
30 Aug 2026
Ships fairly regularly
a new release about every 4 weeks
Nearly every release is documented
notes for 60 of the last 60 stable releases
Nothing withdrawn
no release was ever pulled
7 years old
106 releases · first in 2020
One column per quarter.
Arbitrary code generation vulnerability
Prior to this release, malicious OpenAPI documents could cause openapi-python-client to generate arbitrary code, which
would then be executed by consumers of the generated client.
If you generate code from OpenAPI documents you don't control, you should upgrade to this release as soon as possible
and validate any previously-generated code.
See the GitHub advisory for more details.
uv_build to 0.12 when using --meta=uv (#1473)StrEnum and -> Self (#1474)When two property or parameter names conflicted after conversion to snake_case (e.g. foo-bar and fooBar), the conflict-resolution path preserved delimiters like -, ., and spaces in the generated Python identifiers, producing invalid code which failed generation. Conflicting names now keep their original casing but have any characters which are invalid in Python identifiers stripped (e.g. foobar and fooBar).
Errors and warnings which include a snippet of your OpenAPI document now render that snippet as JSON, making them much easier to read.
ALL custom templates are expected to break with this version as a result of the security fix.
utils global has been renamed to stringsstrings.snake_case() / | snakecase (existing)strings.kebab_case() / | kebabcase (existing)strings.pascal_case() / | pascalcase (existing)python_identifier() (existing)class_name() (existing)strings.safe_for_docstring() / | safe_for_docstring for values which get injected into a """ docstringstrings.in_f_string_literal() / | in_f_string_literal for values that go into f"" f-stringsstrings.in_double_quote_literal() / | in_double_quote_literal for values that go into non-f-string "" literals.as_unembedded_code() / | as_unembedded_code ONLY for PythonCode values—those that are intended to be Python code which is not embedded into any string/docstring. Examples include usages of .python_code, .get_type_string(), .get_instance_type_string(), .get_type_strings_in_union(). You should not assume these values are safe to put in docstrings, string literals, or f-string literals. Use the dedicated helpers for those.Out of an abundance of caution, most Unicode control characters are now stripped from string literals.
If your API uses control characters as part of const values, enums, or JSON body property names you may have issues
with this new version.
Most APIs are not expected to be affected by this change.
Raise minimum httpx version to 0.23.1
Update uv_build to 0.11 when using --meta=uv
uv_build to 0.11 when using --meta=uv (#1434)You can now customize the variable names of the generated string enumerations using the x-enum-varnames openapi extension. Previously, this was only possible for integer enumerations.
sort remaining lazy imports in model template
Update uv_build 0.10 when using --meta=uv
uv_build 0.10 when using --meta=uv (#1396)Apply required overrides from allOf schemas
URL-encode path parameters in generated endpoints
#1360 by @EricAtORS
This fixes:
If a body is not required (the default), it will now:
Unset as part of its type annotation.UNSETUNSETThanks @orelmaliach for the report! Fixes #1354
Remove non-existent CHANGELOG.md references from UV and Poetry templates
uv_build to 0.9#1352 by @johnthagen
uv has been in the 0.9.x release cycle for a while, so update templates to use the corresponding uv_build range.
Since it's now unlikely for breaking changes to affect our usage (and by popular request), the upper bound of ruff has been lifted. Newer versions of…
Both openapi-python-client itself and any generated clients no longer support Python 3.9.
from __future__ import annotationsThis simplifies using forward references with the newer union syntax.
All generated types now use the A | B syntax instead of Union[A, B] or Optional[A].
requires-python upper bounds for uv and PDM (#1329)--fix-onlyThis should enable openapi-python-client to keep auto-fixing lints (like removing unused imports) but not fail to
generate when unfixable lints are violated.
Since it's now unlikely for breaking changes to affect our usage (and by popular request), the upper bound of ruff
has been lifted. Newer versions of openapi-python-client should no longer be required to support newer versions of ruff.
ambigious tilde specifier requires-python with--meta=uv
--meta=uv (#1321)## Features - Reference schema support (#800) (#1307) - Support Ruff 0.13
…meant that reordering union members, while not a breaking change to the API, _would_ be a breaking change for generated clients.
When creating a union with oneOf, anyOf, or a list of type, the name of each variant used to be type_{index}
where the index is based on the order of the types in the union.
This made some modules difficult to understand, what is a my_type_type_0 after all?
It also meant that reordering union members, while not a breaking change to the API, would be a breaking change
for generated clients.
Now, if an individual variant has a title attribute, that title will be used in the name instead.
This is only an enhancement for documents which use title in union variants, and only a breaking change for
inline models (not #/components/schemas which should already have used more descriptive names).
Thanks @wallagib for PR #962!
HTTP statuses like 2XX and default are now supported!
A big thank you to:
Closes #1271 and #832
[!NOTE] Custom template users: the
endpoint.responsestype has changed quite a bit. Check out #1303 for the changes.
Add --meta uv for generating astral-sh/uv compatible packages.
uv_build build backend. (#1290)Import error for types.FileType
types.FileType (#1274) (#1278)## Fixes - Support ruff 0.12
This is not _expected_ to be a breaking change in practice, since the code generated would probably never work.
Previously, when defining a request's body as multipart/form-data, the generator would attempt to generate code
for both object schemas and array schemas. However, most arrays could not generate valid multipart bodies, as
there would be no field names (required to set the Content-Disposition headers).
The code to generate any body for multipart/form-data where the schema is array has been removed, and any such
bodies will be skipped. This is not expected to be a breaking change in practice, since the code generated would
probably never work.
If you have a use-case for multipart/form-data with an array schema, please open a new discussion with an example schema and the desired functional Python code.
Previously, any arrays of values in a multipart/form-data body would be serialized as an application/json part.
This matches the default behavior specified by OpenAPI and supports arrays of files (binary format strings).
However, because this generator doesn't yet support specifying encoding per property, this may result in
now-incorrect code when the encoding was explicitly set to application/json for arrays of scalar values.
PR #938 fixes #692. Thanks @micha91 for the fix, @ratgen and @FabianSchurig for testing, and @davidlizeng for the original report... many years ago 😅.
Adding support for named integer enums via an optional extension, x-enum-varnames.
#1214 by @barrybarrette
Adding support for named integer enums via an optional extension, x-enum-varnames.
This extension is added to the schema inline with the enum definition:
"MyEnum": {
"enum": [
0,
1,
2,
3,
4,
5,
6,
99
],
"type": "integer",
"format": "int32",
"x-enum-varnames": [
"Deinstalled",
"Installed",
"Upcoming_Site",
"Lab_Site",
"Pending_Deinstall",
"Suspended",
"Install_In_Progress",
"Unknown"
]
}
The result:
Lists of model and enum classes should be available to custom templates via the Jinja variables openapi.models and openapi.enums, but these were being
Lists of model and enum classes should be available to custom templates via the Jinja
variables openapi.models and openapi.enums, but these were being passed in a way that made
them always appear empty. This has been fixed so a custom template can now iterate over them.
Closes #1188.
Allow any Mapping in generated from_dict functions
Mapping in generated from_dict functions (#1211)$ref as a referenceIf additional attributes were included with a $ref (for example title or description), the property could be
interpreted as a new type instead of a reference, usually resulting in Any in the generated code.
Now, any sibling properties to $ref will properly be ignored, as per the OpenAPI specification.
Thanks @nkrishnaswami!
Previously, using a $ref to define a response was ignored, the code to call the endpoint was still generated, but the response would not be parsed. No
$ref in responsesPreviously, using a $ref to define a response was ignored, the code to call the endpoint was still generated, but
the response would not be parsed. Now, responses defined with $ref will be used to generate the response model, which
will parse the response at runtime.
If a $ref is incorrect or uses a feature that is not supported by the generator, these endpoints will start failing to
generate.
config available in custom templatesThe configuration options object is now exposed as a variable called config in Jinja2 templates.
docstrings_on_attributes config settingSetting this option to true changes the docstring behavior in model classes: for any attribute that have a non-empty description, instead of describing the attribute as part of the class's docstring, the description will appear in an individual docstring for that attribute.
## Features - allow Ruff 0.9
--overwrite will no longer delete the entire output directory before regenerating. Instead, it will only delete specific, known directories within tha
--overwrite--overwrite will no longer delete the entire output directory before regenerating. Instead, it will only delete
specific, known directories within that directory. Right now, that is only the generated models and api directories.
Other generated files, like README.md, will be overwritten. Extra files and directories outside of those listed above
will be left untouched, so you can any extra modules or files around while still updating pyproject.toml automatically.
Closes #1105.
generate_all_tags config optionYou can now, optionally, generate duplicate endpoint functions/modules using every tag for an endpoint,
not just the first one, by setting generate_all_tags: true in your configuration file.
attrs versionThe minimum attrs dependency version was incorrectly set to 21.3.0. This has been corrected to 22.2.0, the minimum
supported version since openapi-python-client 0.19.1.
Closes #1084, thanks @astralblue!
#1176 by @Viicos
Set defer_build to models that we know will fail to build, and call model_rebuild
in the __init__.py file.
Python 3.8 is no longer supported. "New" 3.9 syntax, like generics on builtin collections, is used both in the generator and the generated code.
Python 3.8 is no longer supported. "New" 3.9 syntax, like generics on builtin collections, is used both in the generator and the generated code.
type is now a reserved field nameBecause type is used in type annotations now, it is no longer a valid field name. Fields which were previously named
type will be renamed to type_.
allow required fields list to be specified as empty
Add UUID string format. Thanks @estyrke!
literal_enums config settingInstead of the default Enum classes for enums, you can now generate Literal sets wherever enum appears in the OpenAPI spec by setting literal_enums: true in your config file.
literal_enums: true
Thanks to @emosenkis for PR #1114 closes #587, #725, #1076, and probably many more. Thanks also to @eli-bl, @expobrain, @theorm, @chrisguillory, and anyone else who helped getting to this design!
HTTPStatus enum when checking response statusesPython 3.13 renamed some of the HTTPStatus enum members, which means clients generated with Python 3.13 may not work
with older versions of Python. This change stops using the HTTPStatus enum directly when checking response statuses.
Statuses will still be checked for validity at generation time, and transformed into HTTPStatus after being checked
at runtime.
This may cause some linters to complain.
When using allOf to extend a base object type, openapi-python-client is now able to handle some kinds of modifications to an existing property that wo
allOfWhen using allOf to extend a base object type, openapi-python-client is now able to handle some kinds of modifications to an existing property that would have previously caused an error:
description.maxLength or pattern.int (resulting in int).format to a string.any with a specific type (resulting in that specific type).default[!NOTE]
patternandmax_lengthare no longer fields onStringProperty, which may impact custom templates.
This also fixes a bug where properties of inline objects (as opposed to references) were not using the merge logic, but were simply overwriting previous definitions of the same property.
Any typeFixed by PR #1109. Thanks @eli-bl!
PR #1103 fixed issue #1091. Thanks @eli-bl!
PR #1103 fixed issue #1091. Thanks @eli-bl!
exclusiveMinimum and exclusiveMaximumFixed by PR #1092. Thanks @mikkelam!
cast import when using constFixed by PR #1072. Thanks @dorcohe!
const booleans and floatsFixed in PR #1086. Thanks @flxdot!
## Features - update Ruff to >=0.2,<0.7
## Features - Update to Ruff 0.5
You can now define and reuse bodies via refs, with a document like this:
You can now define and reuse bodies via refs, with a document like this:
paths:
/something:
post:
requestBody:
"$ref": "#/components/requestBodies/SharedBody"
components:
requestBodies:
SharedBody:
content:
application/json:
schema:
type: string
Thanks to @kigawas and @supermihi for initial implementations and @RockyMM for the initial request.
Closes #633, closes #664, resolves #595.
The update command is no more, you can (mostly) replace its usage with some new flags on the generate command.
update commandThe update command is no more, you can (mostly) replace its usage with some new flags on the generate command.
If you had a package named my-api-client in the current working directory, the update command previously would update the my_api_client module within it. You can now almost perfectly replicate this behavior using openapi-python-client generate --meta=none --output-path=my-api-client/my_api_client --overwrite.
The only difference is that my-api-client would have run post_hooks in the my-api-client directory,
but generate will run post_hooks in the output-path directory.
Alternatively, you can now also run openapi-python-client generate --meta=<your-meta-type> --overwrite to regenerate
the entire client, if you don't care about keeping any changes you've made to the generated client.
Please comment on discussion #824 (or a new discussion, as appropriate) to aid in designing future features that fill any gaps this leaves for you.
--output-path option to generateRather than changing directories before running generate you can now specify an output directory with --output-path.
Note that the project name will not be appended to the --output-path, whatever path you specify is where the
generated code will be placed.
--overwrite flag to generateYou can now tell openapi-python-client to overwrite an existing directory, rather than deleting it yourself before
running generate.
This change switches the YAML parsing library to ruamel.yaml which follows the YAML 1.2 specification. There are breaking changes from YAML 1.1 to 1.2…
const values in responses are now validated at runtimePrior to this version, const values returned from servers were assumed to always be correct. Now, if a server returns
an unexpected value, the client will raise a ValueError. This should enable better usage with oneOf.
PR #1024. Thanks @peter-greenatlas!
This change switches the YAML parsing library to ruamel.yaml which follows the YAML 1.2 specification.
There are breaking changes from YAML 1.1 to 1.2,
though they will not affect most use cases.
PR #1042 fixes #1041. Thanks @rtaycher!
Fixes #926.
[!WARNING] This change is likely to break custom templates. Multipart body handling has been completely split from JSON bodies.
You can now define a content_type_overrides field in your config.yml:
You can now define a content_type_overrides field in your config.yml:
content_type_overrides:
application/zip: application/octet-stream
This allows openapi-python-client to generate code for content types it doesn't recognize.
PR #1010 closes #810. Thanks @gaarutyunov!
Client for pyrightThis should resolve incompatibilities between the generated Client class and the pyright type checker.
PR #1009 closes #909. Thanks @patrick91!
Metadata generated for PDM will now use the new distribution = true syntax instead of package-type = "library". New packages generated with --meta pdm
Metadata generated for PDM will now use the new distribution = true syntax instead of package-type = "library".
New packages generated with --meta pdm will require PDM 2.12.0 or later to build.
UnexpectedStatus exceptionThe error message for UnexpectedStatus exceptions will now include the UTF-8 decoded (ignoring errors) body of the response.
PR #989 implements #840. Thanks @harabat!
Before now, path parameters which were invalid Python identifiers were not allowed, and would fail generation with an "Incorrect path templating" error. In particular, this meant that path parameters with hyphens were not allowed. This has now been fixed!
PR #986 fixed issue #976. Thanks @harabat!
[!WARNING] This change may break custom templates, see this diff if you have trouble upgrading.
This does not affect projects that are not using `--custom-template-path`
This does not affect projects that are not using --custom-template-path
The type of these properties on Endpoint has been changed from Dict[str, Property] to List[Property]:
path_parametersquery_parametersheader_parameterscookie_parametersIf your templates are very close to the default templates, you can probably just remove .values() anywhere it appears.
The type of iter_all_parameters() is also different, you probably want list_all_parameters() instead.
This only affects projects using the generate command, not the update command. The pyproject.toml file generated which configures Ruff for linting and formatting has been updated to the 0.2 syntax, which means it will no longer work with Ruff 0.1.
While fixing #922, some naming strategies were updated. These should mostly be backwards compatible, but there may be some small differences in generated code. Make sure to check your diffs before pushing updates to consumers!
If you have two parameters to an endpoint named mixedCase and mixed_case, previously, this was a conflict and the endpoint would not be generated.
Now, the generator will skip snake-casing the parameters and use the names as-is. Note that this means if neither of the parameters was snake case, neither will be in the generated code.
Fixes #922 reported by @macmoritz & @benedikt-bartscher.
If you had an object with two properties, where the names differed only by case, conflicting properties would be generated in the model, which then failed the linting step (when using default config). For example, this:
type: "object"
properties:
MixedCase:
type: "string"
mixedCase:
type: "string"
Would generate a class like this:
class MyModel:
mixed_case: str
mixed_case: str
Now, neither of the properties will be forced into snake case, and the generated code will look like this:
class MyModel:
MixedCase: str
mixedCase: str
Nested union types (unions of unions) were generating isinstance() checks that were not valid (at least for Python 3.9).
Nested union types (unions of unions) were generating isinstance() checks that were not valid (at least for Python 3.9).
Thanks to @codebutler for PR #959 which fixes #958 and #967.
The default metadata is still --meta=poetry, which generates a pyproject.toml file with Poetry-specific metadata. This change adds the --meta=pdm opti
--meta=pdm option for generating PEP621 + PDM metadataThe default metadata is still --meta=poetry, which generates a pyproject.toml file with Poetry-specific metadata.
This change adds the --meta=pdm option which includes PDM-specific metadata, but also
standard PEP621
metadata. This may be useful as a starting point for other dependency managers & build tools (like Hatch).
data attribute to Response objectPR #767
In custom templates, you can now access a response.data attribute that contains the original OpenAPI definition of the
response (Response Object or Reference Object).
UP rule for generated Ruff configThis enables pyupgrade-like improvements which should replace some
.format() calls with f-strings.
--meta=nonePR #940 fixes issue #939. Thanks @satwell!
Due to the lack of pyproject.toml, Ruff was not getting configured properly when --meta=none.
As a result, it didn't clean up common generation issues like duplicate imports, which would then cause errors from
linters.
This is now fixed by changing the default post_hook to ruff check . --fix --extend-select=I when --meta=none.
Using generate --meta=none should now be almost identical to the code generated by update.
If a schema has both type = "boolean" and enum defined, a normal boolean property will now be created. Previously, the generator would error.
Unset types from generated types.py (#927)If a schema has both type = "boolean" and enum defined, a normal boolean property will now be created.
Previously, the generator would error.
Note that the generate code will not correctly limit the values to the enum values. To work around this, use the
OpenAPI 3.1 const instead of enum to generate Python Literal types.
Thanks for reporting #922 @macmoritz!
This generator only supports enum values that are strings or integers.
Previously, this was handled at the parsing level, which would cause the generator to fail if there were any unsupported values in the document.
Now, the generator will correctly keep going, skipping only endpoints which contained unsupported values.
Thanks for reporting #922 @macmoritz!
Fixes #756 and #928. Arrays within unions (which, as of 0.17 includes nullable arrays) would generate invalid code.
Thanks @kgutwin and @diesieben07!
In previous versions, setting _either_ nullable: true or required: false on a query parameter would act like both were set, resulting in a type signat
In previous versions, setting either nullable: true or required: false on a query parameter would act like both were set, resulting in a type signature like Union[None, Unset, YourType]. This special case has been removed, query parameters will now act like all other types of parameters.
PR #900 addresses #822.
Where previously there would be one body parameter per supported content type, now there is a single body parameter which takes a union of all the possible inputs. This correctly models the fact that only one body can be sent (and ever would be sent) in a request.
For example, when calling a generated endpoint, code which used to look like this:
post_body_multipart.sync_detailed(
client=client,
multipart_data=PostBodyMultipartMultipartData(),
)
Will now look like this:
post_body_multipart.sync_detailed(
client=client,
body=PostBodyMultipartBody(),
)
Note that both the input parameter name and the class name have changed. This should result in simpler code when there is only a single body type and now produces correct code when there are multiple body types.
The generator will now attempt to generate code for OpenAPI documents with versions 3.1.x (previously, it would exit immediately on seeing a version other than 3.0.x). The following specific OpenAPI 3.1 features are now supported:
null as a typetype: [string, null])const (defines Literal types)The generator does not currently validate that the OpenAPI document is valid for a specific version of OpenAPI, so it may be possible to generate code for documents that include both removed 3.0 syntax (e.g., nullable) and new 3.1 syntax (e.g., null as a type).
Thanks to everyone who helped make this possible with discussions and testing, including:
requestBodyPR #900 addresses #822.
It is now possible in some circumstances to generate valid code for OpenAPI documents which have multiple possible requestBody values. Previously, invalid code could have been generated with no warning (only one body could actually be sent).
Only one content type per "category" is currently supported at a time. The categories are:
application/jsonapplication/octet-streamapplication/x-www-form-urlencodedmultipart/form-dataIn previous versions, a request body that was similar to a known content type would use that content type in the request. For example application/json would be used for application/vnd.api+json. This was incorrect and could result in invalid requests being sent.
Now, the content type defined in the OpenAPI document will always be used.
## Features ### Support httpx 0.26
black is no longer a runtime dependency, so if you have them set in custom post_hooks in a config file, you'll need to make sure they're being install
black is no longer a runtime dependency, so if you have them set in custom post_hooks in a config file, you'll need to make sure they're being installed manually. ruff is now installed and used by default instead.
isort and autoflake are no longer runtime dependencies, so if you have them set in custom post_hooks in a config file, you'll need to make sure they're being installed manually. ruff is now installed and used by default instead.
text/* content types in responsesWithin an API response, any content type which starts with text/ will now be treated the same as text/html already was—they will return the response.text attribute from the httpx Response.
Thanks to @fdintino for the initial implementation, and thanks for the discussions from @kairntech, @rubenfiszel, and @antoneladestito.
Closes #797 and #821.
application/octet-stream request bodiesEndpoints that accept application/octet-stream request bodies are now supported using the same File type as octet-stream responses.
Thanks to @kgutwin for the implementation and @rtaycher for the discussion!
PR #899 closes #588
pass statements from generated code## Features ### support httpx 0.25 (#854) ### Support content-type with attributes (#655, #809, #858). Thanks @sherbang!
## Features ### Upgrade internal Pydantic use to v2. Thanks @KristinnVikar! (#779) ## Fixes ### Naming conflicts when properties are named "field" or
Some features of generated clients already failed at runtime when using httpx < 0.20, but now the minimum version is enforced at generation time.
Some features of generated clients already failed at runtime when using httpx < 0.20, but now the minimum version is enforced at generation time.
Client and AuthenticatedClient now reuse an internal httpx.Client (or AsyncClient)—keeping connections open between requests. This will improve performance overall, but may cause resource leaking if clients are not closed properly. The new clients are intended to be used via context managers—though for compatibility they don't have to be used with context managers. If not using a context manager, connections will probably leak. Note that once a client is closed (by leaving the context manager), it can no longer be used—and attempting to do so will raise an exception.
APIs should now be called like:
with client as client:
my_api.sync(client)
another_api.sync(client)
# client is closed here and can no longer be used
Generated READMEs reflect the new syntax, but READMEs for existing generated clients should be updated manually. See this diff for inspiration.
@define and field APIsSee the attrs docs for more information on how these may affect you.
Client and AuthenticatedClientThe following attributes have been removed from Client and AuthenticatedClient:
base_url—this can now only be set via the initializercookies—set at initialization or use .with_cookies()headers—set at initialization or use .with_headers()timeout—set at initialization or use .with_timeout()verify_ssl—this can now only be set via the initializerfollow_redirects—this can now only be set via the initializertimeout param and with_timeout now take an httpx.Timeout instead of a floatAuthenticatedClient no longer inherits from ClientThe API of AuthenticatedClient is still a superset of Client, but the two classes no longer share a common base class.
httpx clientsThere are many use-cases where customizing the underlying httpx client directly is necessary. Some examples are:
The new Client and AuthenticatedClient classes come with several methods to customize underlying clients. You can pass arbitrary arguments to httpx.Client or httpx.AsyncClient when they are constructed:
client = Client(base_url="https://api.example.com", httpx_args={"proxies": {"https://": "https://proxy.example.com"}})
The underlying clients are constructed lazily, only when needed. httpx_args are stored internally in a dictionary until the first request is made.
You can force immediate construction of an underlying client in order to edit it directly:
import httpx
from my_api import Client
client = Client(base_url="https://api.example.com")
sync_client: httpx.Client = client.get_httpx_client()
sync_client.timeout = 10
async_client = client.get_async_httpx_client()
async_client.timeout = 15
You can also completely override the underlying clients:
import httpx
from my_api import Client
client = Client(base_url="https://api.example.com")
# The params you put in here ^ are discarded when you call set_httpx_client or set_async_httpx_client
sync_client = httpx.Client(base_url="https://api.example.com", timeout=10)
client.set_httpx_client(sync_client)
async_client = httpx.AsyncClient(base_url="https://api.example.com", timeout=15)
client.set_async_httpx_client(async_client)
This happens every time you use the same Client or AuthenticatedClient instance for multiple requests, however it is best to use a context manager (e.g., with client as client:) to ensure the client is closed properly.
Allow parameters named "client" and "url" [#758, #762, #765]. Thanks @truenicoco & @juanber84!
Drop support for Python 3.7, put minimum version limit on Black
Unset (e.g., using if statements to check type) [#714, #752]. Thanks @taasan & @mcclurem!Unset (e.g., using if statements to check type) [#714, #752]. Thanks @taasan & @mcclurem! (#752)## 0.13.4 ### Features - support httpx 0.24
Extend the UnexpectedStatus exception to include the response's content (#729). Thanks @expobrain!
Always generate enums with sorted members (#728). Thanks @expobrain!
required field in parameters included with $ref (#737). Thanks @robertschweizer!Add http_timeout config to set timeout getting document via --url [#718]. Thanks @Kircheneer!
http_timeout config to set timeout getting document via --url [#718]. Thanks @Kircheneer!run post_hooks in package directory instead of current directory if meta=none [#696, #697]. Thanks @brenmous and @wallagib!
post_hooks in package directory instead of current directory if meta=none [#696, #697]. Thanks @brenmous and @wallagib!Client.get_headers function [#713]. Thanks @rtaycher!Add raise_on_unexpected_status flag to generated Client [#593]. Thanks @JamesHinshelwood, @ramnes, @gwenshap, @theFong!
raise_on_unexpected_status flag to generated Client [#593]. Thanks @JamesHinshelwood, @ramnes, @gwenshap, @theFong!use_path_prefixes_for_title_model_names config option for simpler model names [#559, #560]. Thanks @rtaycher!+json [#706, #709]. Thanks @XioNoX and @mtovt!## 0.12.2 ### Fixes - Support Python 3.11.0
## 0.12.1 ### Fixes - Version bump due to PyPI error
improve the error message when parsing a response fails [#659]. Thanks @supermihi!
support #/components/parameters references [#288, #615, #653]. Thanks @jsanchez7SC!
#/components/parameters references [#288, #615, #653]. Thanks @jsanchez7SC!Invalid code generation with some oneOf and anyOf combinations [#603, #642]. Thanks @jselig-rigetti!
oneOf and anyOf combinations [#603, #642]. Thanks @jselig-rigetti!Allow tokenUrl to be relative [#618]. Thanks @Fokko!
typos in generated README (#586). Thanks @adelevie!
Allow httpx 0.22.\* in generated clients [#577]
Your coding agent can read these notes before it upgrades. Set up the MCP server →