Changelog

5.99.1

(fix): Error responses that reference the same nullable schema from two or more endpoints now generate a typed error body instead of an untyped one. Previously two responses referring to the identical nullable schema were treated as conflicting shapes and the body was downgraded to unknown.

This changes generated error-handling signatures for specs with that shape, so those SDKs may warrant a major bump. The trigger condition is narrow: two or more endpoints must share a status code whose error schema is the same nullable schema. Errors declared by a single endpoint, and shared errors whose schemas are not nullable, were already typed and are unaffected.

If your spec has that shape, error handling that indexes into the body must move to the typed field:

• Go fails to compile: err.Body.(map[string]any)["error_code"] becomes err.Body.ErrorCode.
• Java fails to compile: casts such as (Map<String, Object>) e.body() no longer apply.
• Python fails at runtime, not at build time: the body is parsed into a model, so e.body["error_code"] raises TypeError: 'ErrorBody' object is not subscriptable the first time the error path fires. Use e.body.error_code.
• TypeScript is unaffected in practice, since the body was already unknown and had to be narrowed.

5.99.0

(feat): Add the respect-parameter-content OpenAPI setting. When enabled, header parameters that declare their schema under content (e.g. a header whose value is a JSON-encoded object) are typed from that schema instead of falling back to a string, so the referenced object’s fields are preserved in SDKs and the API reference playground.